পরিস্থিতি
আজ সন্ধ্যায় আমি স্ট্যাকওভারফ্লোতে একটি প্রশ্নের উত্তর দিয়েছিলাম ।
প্রশ্নটি:
কোনও বিদ্যমান অবজেক্টের সম্পাদনা সংগ্রহস্থল স্তরে বা পরিষেবাতে করা উচিত?
উদাহরণস্বরূপ যদি আমার কোনও haveণ আছে এমন কোনও ব্যবহারকারী থাকে। আমি তার debtণ পরিবর্তন করতে চাই। আমি কি এটি ইউজাররপোসিটরিতে বা পরিষেবাতে করব যেমন উদাহরণস্বরূপ কোনও জিনিস পেয়ে, এডিট করে এবং এটি সংরক্ষণ করে কেনা সার্ভিস?
আমার উত্তর:
আপনার একই পদার্থকে কোনও পরিবর্তনের দায়িত্ব ছেড়ে দেওয়া উচিত এবং এই বস্তুটি পুনরুদ্ধার করতে সংগ্রহস্থলটি ব্যবহার করা উচিত।
উদাহরণ পরিস্থিতি:
class User {
private int debt; // debt in cents
private string name;
// getters
public void makePayment(int cents){
debt -= cents;
}
}
class UserRepository {
public User GetUserByName(string name){
// Get appropriate user from database
}
}আমি একটি মন্তব্য পেয়েছি:
ব্যবসায়িক যুক্তি সত্যই কোনও পরিষেবায় হওয়া উচিত। কোনও মডেল নয়।
ইন্টারনেট কী বলে?
সুতরাং, এটি আমাকে অনুসন্ধান করল যেহেতু আমি কখনই (সচেতনভাবে) কোনও পরিষেবা স্তর ব্যবহার করি নি। আমি সার্ভিস লেয়ার প্যাটার্ন এবং ইউনিট অফ ওয়ার্কের প্যাটার্নটি পড়তে শুরু করেছি তবে এখন পর্যন্ত আমি বলতে পারি না যে আমি নিশ্চিত যে কোনও পরিষেবা স্তর ব্যবহার করতে হবে।
উদাহরণস্বরূপ, এনেমিক ডোমেন মডেলটির অ্যান্টি-প্যাটার্ন সম্পর্কিত মার্টিন ফাউলারের এই নিবন্ধটি দেখুন :
ডোমেন স্পেসে নামগুলির নাম অনুসারে অনেকগুলি অবজেক্ট রয়েছে এবং এই বিষয়গুলি সত্য ডোমেন মডেলগুলির সমৃদ্ধ সম্পর্ক এবং কাঠামোর সাথে সংযুক্ত connected আপনি যখন আচরণটি দেখেন তখন ধরা পড়ে, এবং আপনি বুঝতে পেরেছেন যে এই জিনিসগুলির উপর খুব কমই কোনও আচরণ রয়েছে, যা সেগুলি গিটার এবং সেটটারগুলির ব্যাগের চেয়ে কিছুটা বেশি করে তোলে। প্রকৃতপক্ষে প্রায়শই এই মডেলগুলি ডিজাইনের বিধিগুলি নিয়ে আসে যা বলে যে আপনি ডোমেন অবজেক্টগুলিতে কোনও ডোমেন যুক্তি স্থাপন করবেন না। পরিবর্তে সেখানে পরিষেবা সামগ্রীর একটি সেট রয়েছে যা সমস্ত ডোমেন যুক্তিকে ক্যাপচার করে। এই পরিষেবাগুলি ডোমেন মডেলের শীর্ষে থাকে এবং ডেটার জন্য ডোমেন মডেলটি ব্যবহার করে।
(...) ডোমেইন অবজেক্টে যে যুক্তিটি হওয়া উচিত তা হ'ল ডোমেন লজিক - বৈধতা, গণনা, ব্যবসায়ের নিয়ম - আপনি যা কল করতে পছন্দ করেন না কেন।
আমার কাছে, পরিস্থিতিটি ঠিক কী রকম হয়েছিল তা দেখে মনে হয়েছিল: আমি সেই শ্রেণীর অভ্যন্তরে এমন পদ্ধতিগুলি চালু করে যা একটি বস্তুর ডেটা ম্যানিপুলেশনকে সমর্থন করে। তবে আমি বুঝতে পারি যে এটি কোনওভাবেই দেওয়া উচিত, এবং এই পদ্ধতিগুলি কীভাবে চালিত হয় তার সাথে সম্ভবত আরও কিছু করার দরকার আছে (একটি সংগ্রহস্থল ব্যবহার করে)।
আমার এই অনুভূতিও ছিল যে সেই নিবন্ধে (নীচে দেখুন) কোনও সার্ভিস লেয়ারকে প্রকৃত কাজ-নিবিড় স্তরের চেয়ে অন্তর্নিহিত মডেলটিতে কাজ করে এমন একটি ফলস্বরূপ হিসাবে বেশি বিবেচিত হয় ।
অ্যাপ্লিকেশন স্তর [পরিষেবা স্তরটির জন্য তার নাম]: সফ্টওয়্যারটি যে কাজগুলি করার কথা বলেছিল তা সংজ্ঞায়িত করে এবং সংবেদনশীল ডোমেন অবজেক্টগুলিকে সমস্যা সমাধানের নির্দেশ দেয়। এই স্তরটি যে সমস্ত কাজের জন্য দায়বদ্ধ তা ব্যবসায়ের পক্ষে অর্থপূর্ণ বা অন্যান্য সিস্টেমের অ্যাপ্লিকেশন স্তরগুলির সাথে মিথস্ক্রিয়া করার জন্য প্রয়োজনীয়। এই স্তরটি পাতলা রাখা হয়। এতে ব্যবসায়িক বিধি বা জ্ঞান নেই, তবে কেবল কার্যগুলি সমন্বয় করে এবং পরবর্তী স্তরটিতে ডোমেন অবজেক্টের সহযোগিতায় কাজ ডেলিগেট করে। এটিতে ব্যবসায়ের পরিস্থিতি প্রতিফলিত করার মতো রাষ্ট্র নেই, তবে এটিতে এমন অবস্থা থাকতে পারে যা ব্যবহারকারী বা প্রোগ্রামের জন্য কোনও কাজের অগ্রগতি প্রতিফলিত করে।
যা এখানে আরও শক্তিশালী করা হয়েছে :
পরিষেবা ইন্টারফেস। পরিষেবাদি একটি পরিষেবা ইন্টারফেস প্রকাশ করে যেখানে সমস্ত অন্তর্মুখী বার্তা প্রেরণ করা হয়। আপনি কোনও পরিষেবা ইন্টারফেসটিকে ফলদরূপে ভাবতে পারেন যা অ্যাপ্লিকেশনটিতে প্রয়োগ করা ব্যবসায়িক যুক্তি (সাধারণত, ব্যবসায়িক স্তরের যুক্তি) সম্ভাব্য গ্রাহকদের কাছে প্রকাশ করে।
এবং এখানে :
পরিষেবা স্তরটি কোনও অ্যাপ্লিকেশন বা ব্যবসায়ের যুক্তিবিহীন হওয়া উচিত এবং প্রাথমিকভাবে কয়েকটি উদ্বেগের দিকে ফোকাস করা উচিত। এটিতে বিজনেস লেয়ারের কলগুলি মোড়ানো উচিত, আপনার ক্লায়েন্টরা বুঝতে পারে এমন একটি সাধারণ ভাষায় আপনার ডোমেনটিকে অনুবাদ করতে হবে এবং সার্ভার এবং অনুরোধকারী ক্লায়েন্টের মধ্যে যোগাযোগের মাধ্যমটি পরিচালনা করতে হবে।
সার্ভিস লেয়ার সম্পর্কে কথা বলে এমন অন্যান্য সংস্থানগুলির সাথে এটি মারাত্মক বৈপরীত্য :
পরিষেবা স্তরটিতে এমন একাধিক পদ্ধতি রয়েছে যা একই লেনদেনের সাথে জড়িত ক্রিয়াগুলির সাথে কাজের একক classes
বা আমি ইতিমধ্যে সংযুক্ত একটি প্রশ্নের দ্বিতীয় উত্তর :
এক পর্যায়ে, আপনার অ্যাপ্লিকেশনটি কিছু ব্যবসায়ের যুক্তি চাইবে। এছাড়াও, আপনি যাতে কোনও খারাপ বা নন-পারফর্মিংয়ের অনুরোধ করা হচ্ছে না তা নিশ্চিত করতে আপনি ইনপুটটি বৈধতা দিতে চাইতে পারেন। এই যুক্তিটি আপনার পরিষেবা স্তরের অন্তর্গত।
"সমাধান"?
এই উত্তরের নির্দেশিকাগুলি অনুসরণ করে , আমি নিম্নলিখিত পদ্ধতির সাথে উপস্থিত হয়েছি যা কোনও পরিষেবা স্তর ব্যবহার করে:
class UserController : Controller {
private UserService _userService;
public UserController(UserService userService){
_userService = userService;
}
public ActionResult MakeHimPay(string username, int amount) {
_userService.MakeHimPay(username, amount);
return RedirectToAction("ShowUserOverview");
}
public ActionResult ShowUserOverview() {
return View();
}
}
class UserService {
private IUserRepository _userRepository;
public UserService(IUserRepository userRepository) {
_userRepository = userRepository;
}
public void MakeHimPay(username, amount) {
_userRepository.GetUserByName(username).makePayment(amount);
}
}
class UserRepository {
public User GetUserByName(string name){
// Get appropriate user from database
}
}
class User {
private int debt; // debt in cents
private string name;
// getters
public void makePayment(int cents){
debt -= cents;
}
}উপসংহার
সব মিলিয়ে এখানে খুব বেশি পরিবর্তন হয়নি: কন্ট্রোলার থেকে কোডটি পরিষেবা স্তরে সরে গেছে (যা ভাল জিনিস, সুতরাং এই পদ্ধতির একটি উল্টো দিক রয়েছে)। তবে এটি আমার আসল উত্তরের সাথে কিছু করার মতো বলে মনে হচ্ছে না।
আমি বুঝতে পারি যে নকশার নিদর্শনগুলি গাইডলাইনস, যখনই সম্ভব হবে তখন প্রয়োগ করার জন্য পাথরের বিধি বিধান নয়। তবুও আমি পরিষেবা স্তরটির কীভাবে এটি বিবেচনা করা উচিত তার একটি নির্দিষ্ট ব্যাখ্যা খুঁজে পাইনি found
এটি কি নিয়ামকের কাছ থেকে কেবল যুক্তি বের করে তার পরিবর্তে কোনও পরিষেবার ভিতরে রেখে দেওয়ার উপায়?
এটি কি নিয়ামক এবং ডোমেনের মধ্যে একটি চুক্তি গঠনের কথা?
ডোমেন এবং পরিষেবা স্তরের মধ্যে একটি স্তর থাকা উচিত?
এবং, শেষ কিন্তু অন্তত নয়: মূল মন্তব্য অনুসরণ করে
ব্যবসায়িক যুক্তি সত্যই কোনও পরিষেবায় হওয়া উচিত। কোনও মডেল নয়।
এটা কি সঠিক?
- আমি কীভাবে মডেলটির পরিবর্তে কোনও পরিষেবাতে আমার ব্যবসায়ের যুক্তি যুক্ত করব?
