কোনটি আরও ভাল হিসাবে বিবেচিত:
- একটি নির্দেশনা রয়েছে যা সরাসরি পরিষেবার সাথে যোগাযোগ করে
অথবা
- এমন কোনও নির্দেশিকা রয়েছে যা নির্দিষ্ট হুকগুলি প্রকাশ করে যা নিয়ন্ত্রণকারী আচরণকে বাঁধতে পারে (পরিষেবার সাথে জড়িত)?
কোনটি আরও ভাল হিসাবে বিবেচিত:
অথবা
উত্তর:
সংক্ষিপ্ত (কোড-ওয়াইজ), (সম্ভাব্য) পুনঃব্যবহারযোগ্য এবং কোনও কার্যকারিতার দিক দিয়ে এর সীমিত সুযোগ থাকতে পারে তখন একটি নির্দেশিকা সেরা (একটি থাম্বের নিয়ম হিসাবে) হয়। এমন নির্দেশিকা তৈরি করা যাতে ইউআই অন্তর্ভুক্ত থাকে এবং কোনও পরিষেবার উপর নির্ভর করে (যে আমি ব্যাকএন্ডের সাথে সংযোগ পরিচালনা করি বলে মনে করি), কেবল এটি কেবল 2 টি কার্যকরী ভূমিকা দেয় না:
তবে এটিকে আবার কম ব্যবহারযোগ্য করে তুলছে, কারণ আপনি এটি আর কোনও পরিষেবা বা অন্য কোনও ইউআই দিয়ে (কমপক্ষে সহজেই সহজে না) ব্যবহার করতে পারবেন না।
এই সিদ্ধান্তগুলি নেওয়ার সময়, আমি প্রায়শই অন্তর্নির্মিত এইচটিএমএল উপাদানগুলির সাথে তুলনা করি: উদাহরণস্বরূপ <input>
, <textarea>
বা <form>
: তারা কোনও নির্দিষ্ট ব্যাকএন্ডের থেকে সম্পূর্ণ স্বাধীন। এইচটিএমএল 5 <input>
উপাদানটিকে কয়েকটি অতিরিক্ত প্রকার দিয়েছে, যেমন date
, যা এখনও ব্যাকএন্ডের থেকে আলাদা এবং যেখানে ডেটা ঠিক যায় বা এটি কীভাবে ব্যবহৃত হয়। এগুলি বিশুদ্ধরূপে ইন্টারফেসের উপাদান। আপনার কাস্টম উইজেটগুলি, নির্দেশাবলী ব্যবহার করে নির্মিত, আমার মনে হয় যদি সম্ভব হয় তবে একই প্যাটার্নটি অনুসরণ করা উচিত।
তবে এটি গল্পের শেষ নয়। অন্তর্নির্মিত এইচটিএমএল উপাদানগুলির সাথে সাদৃশ্য ছাড়িয়ে আপনি পুনরায় ব্যবহারযোগ্য নির্দেশিকা তৈরি করতে পারেন যা উভয়ই পরিষেবাগুলিকে কল করে এবং খাঁটি ইউআই নির্দেশিকা ব্যবহার করতে পারে, যেমন এটি ব্যবহার করতে পারে <textarea>
। বলুন যে আপনি নিম্নলিখিত হিসাবে কিছু এইচটিএমএল ব্যবহার করতে চান:
<document document-url="'documents/3345.html'">
<document-data></document-data>
<comments></comments>
<comment-entry></comment-entry>
</document>
commentEntry
নির্দেশিকাটি কোড আপ করতে , আপনি একটি খুব ছোট নির্দেশিকা তৈরি করতে পারেন যাতে কেবলমাত্র নিয়ামক থাকে যা কোনও ইউআই-উইজেটের সাথে কোনও পরিষেবাতে লিঙ্ক করে। কিছুটা এইরকম:
app.directive('commentEntry', function (myService) {
return {
restrict: 'E',
template: '<comment-widget on-save="save(data)" on-cancel="cancel()"></comment-widget>',
require: '^document',
link: function (scope, iElement, iAttrs, documentController) {
// Allow the controller here to access the document controller
scope.documentController = documentController;
},
controller: function ($scope) {
$scope.save = function (data) {
// Assuming the document controller exposes a function "getUrl"
var url = $scope.documentController.getUrl();
myService.saveComments(url, data).then(function (result) {
// Do something
});
};
}
};
});
এটি একটি চূড়ান্ত দিকে নিয়ে যাওয়া, আপনার ng-controller
এইচটিএমএলে কোনও ম্যানুয়াল বৈশিষ্ট্য থাকতে হবে না : আপনি প্রত্যক্ষ নির্দেশিকা ব্যবহার করে এটি করতে পারবেন, যতক্ষণ না প্রত্যেকে সরাসরি "স্পষ্ট" ইউআই "ভূমিকা বা পরিষ্কার" ডেটা "ভূমিকা রাখে।
আমার একটি নেতিবাচক দিকটি উল্লেখ করা উচিত: এটি প্রয়োগে আরও "চলন্ত অংশগুলি" দেয় যা কিছুটা জটিলতা যোগ করে। যাইহোক, যদি প্রতিটি অংশের একটি সুস্পষ্ট ভূমিকা থাকে, এবং ভাল (ইউনিট + ই 2 ই পরীক্ষিত) হয় তবে আমি এটি যুক্তিযুক্ত করব যে এটি দীর্ঘকালীন এবং এটির সামগ্রিক উপকার।
আমাকে মিশাল চেরেমজার উত্তরটির সাথে একমত হতে দিন।
যদিও তার উত্তর তাত্ত্বিকভাবে সঠিক, এটি বাস্তব বিশ্বের পক্ষে খুব বেশি ব্যবহারিক নয়।
আমি বলছি যেহেতু আমি এটির মতোই ভাবতাম এবং এটি একটি বিশাল বাস্তব বিশ্ব অ্যাপ্লিকেশনটিতে প্রয়োগ করার চেষ্টা করেছি যে আমি এবং আমার দলটি তৈরি করছে এবং এটি কেবল খুব ঝামেলার হয়ে উঠেছে।
এইচটিএমএল ভাষার সাথে সাদৃশ্যটি ভাল নয়, কারণ আপনার সাধারণ উদ্দেশ্য, অত্যন্ত পুনরায় ব্যবহারযোগ্য নির্দেশিকা তৈরি করার প্রচেষ্টা করা উচিত নয়, কারণ আপনি ওয়েব ব্রাউজারের মতো জেনেরিক অ্যাপ্লিকেশন তৈরি করছেন না।
পরিবর্তে, আপনার নিজের ডোমেনে বাস করে এমন অ্যাপ্লিকেশনটির জন্য আপনার একটি ডোমেন নির্দিষ্ট ভাষা (ডিএসএল) তৈরি করার জন্য নির্দেশিকাগুলি ব্যবহার করা উচিত।
এর অর্থ এই নয় যে সমস্ত নির্দেশ জেনেরিক হওয়া উচিত নয়। কিছু হতে পারে, যদি এটি তাদের প্রকৃতির হয়। যদি আপনি কোনও কাস্টম তারিখ চয়নকারী তৈরি করে থাকেন তবে যেকোন উপায়ে এটিকে জেনেরিক এবং অ্যাপ্লিকেশনগুলিতে পুনরায় ব্যবহারযোগ্য করে তুলুন।
তবে আপনি যদি কোনও লগইন বাক্সের মতো এমন কিছু তৈরি করে যা আপনার পিছনের দিকে আবদ্ধ থাকে, কেবল এটি করুন।
থাম্বের একমাত্র নিয়মটি হ'ল: কখনও কোড নকল করবেন না (কারখানা এবং পরিষেবাদিগুলিতে বিমূর্ত ছোট টুকরা) এবং নির্ভরতা ইনজেকশনের মাধ্যমে এটিকে পরীক্ষার যোগ্য করে তুলুন। ভাগ্যক্রমে, কৌণিকের সাথে, সেগুলি একটি কেকের টুকরা।
সহজবোধ্য রাখো. :)
আমি মনে করি "পরিষেবাটি কোনও নির্দেশনার সাথে যোগাযোগ করা উচিত" প্রশ্নটি আপনার পরিষেবা কী করছে তার উপর নির্ভর করে।
আমার পরিষেবাগুলির সাথে ইন্টারেক্টিভ ইন্টারেক্টিভ হয়েছে যা এইচটিটিপি অনুরোধগুলির সাথে কিছু না করে এবং আমি মনে করি এটি একটি ভাল প্যাটার্ন। পরিষেবাদি / কারখানাগুলি আরও ডেটা ওরিয়েন্টেড লজিককে সংযুক্ত করার জন্য দুর্দান্ত, এবং উপস্থাপনা ওরিয়েন্টেড লজিককে এনক্যাপসুলেট করার জন্য দিকনির্দেশনা দুর্দান্ত। কৌণিক দস্তাবেজে পরিষেবার বর্ণিত উদ্দেশ্য হ'ল: আপনি আপনার অ্যাপ্লিকেশন জুড়ে কোডটি সংগঠিত করতে এবং ভাগ করতে পরিষেবাগুলি ব্যবহার করতে পারেন " এটি বেশ বিস্তৃত তবে দিকনির্দেশনায় সেই লক্ষ্য অর্জনের জন্য পরিষেবাগুলি ব্যবহার করা যেতে পারে।
বলা হচ্ছে, কিছু ক্ষেত্রে এটি তৈরি করার ইচ্ছাটি আমি বুঝতে পারি যাতে নির্দেশাবলী সরাসরি কোনও HTTP অনুরোধ না করে। আবার, এটি পরিষেবা এবং আপনি কীভাবে আপনার পরিষেবাগুলি সংগঠিত করছেন তার উপর নির্ভর করে।
অ্যাঙ্গুলারজেএস ফ্রেমওয়ার্ক অনুসারে, সার্ভার থেকে কোনও তথ্য পাওয়ার জন্য আমাদের কারখানাগুলি / পরিষেবাগুলি সিঙ্গলটন করা উচিত। যাতে এই কারখানাগুলি একই পুনরায় না লিখে অ্যাপ্লিকেশন জুড়ে পুনরায় ব্যবহার করা যায় dire নির্দেশের অভ্যন্তরে আমরা এই কারখানাগুলিকে এপি / সার্ভার থেকে ডেটা আনার জন্য কল করতে পারি।