තත්ත්වය
අද සවස මම ස්ටැක් ඕවර්ෆ්ලෝ හි ප්‍රශ්නයකට පිළිතුරක් දුන්නා .
ප්රශ්නය:
පවත්නා වස්තුවක් සංස්කරණය කිරීම නිධිය ස්ථරයේ හෝ සේවයේ කළ යුතුද?
උදාහරණයක් ලෙස මට ණය ඇති පරිශීලකයෙකු සිටී නම්. මට ඔහුගේ ණය වෙනස් කිරීමට අවශ්‍යයි. මම එය පරිශීලක ගබඩාවේ හෝ සේවයේ කළ යුතුද? උදාහරණයක් ලෙස වස්තුවක් ලබා ගැනීමෙන්, සංස්කරණය කිරීමෙන් සහ සුරැකීමෙන් සේවා මිලදී ගැනීම?
මගේ පිළිතුර:
එම වස්තුවට විකෘතියක් කිරීමේ වගකීම ඔබ අතහැර දමා මෙම වස්තුව ලබා ගැනීමට නිධිය භාවිතා කළ යුතුය.
උදාහරණ තත්වය:
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
}
}
මට ලැබුණු අදහසක්:
ව්‍යාපාර තර්කනය සැබවින්ම සේවාවක තිබිය යුතුය. ආකෘතියක නොවේ.
අන්තර්ජාලය පවසන්නේ කුමක්ද?
ඉතින්, මම කිසි විටෙකත් (දැනුවත්ව) සේවා තට්ටුවක් භාවිතා කර නැති නිසා මෙය මා සෙව්වේය. මම සේවා ස්ථර රටාව සහ වැඩ ඒකකය පිළිබඳ කියවීම ආරම්භ කළ නමුත් සේවා ස්ථරයක් භාවිතා කළ යුතු යැයි මට විශ්වාසයි.
රක්තහීන වසම් ආකෘතියක ප්‍රති-රටාව පිළිබඳ මාටින් ෆෝලර්ගේ මෙම ලිපිය උදාහරණයක් ලෙස ගන්න :
වස්තූන් ඇත, බොහෝ ඒවා වසම් අවකාශයේ නාම පද වලින් නම් කර ඇති අතර මෙම වස්තූන් සැබෑ වසම් ආකෘති සතුව ඇති පොහොසත් සම්බන්ධතා සහ ව්‍යුහය සමඟ සම්බන්ධ වේ. අල්ලා ගැනීම සිදුවන්නේ ඔබ හැසිරීම දෙස බලන විට වන අතර, මෙම වස්තූන් මත කිසිදු හැසිරීමක් නැති බව ඔබට වැටහී ඇති අතර, ඒවා ලබා ගන්නන්ගේ සහ සැකසුම් කරුවන්ගේ බෑග් වලට වඩා මඳක් වැඩි වේ. ඇත්ත වශයෙන්ම බොහෝ විට මෙම ආකෘතීන් නිර්මාණ නීති රීති සමඟ එන අතර ඔබ වසම් වස්තු තුළ කිසිදු ඩොමේන් තර්කනයක් නොතැබිය යුතුය. ඒ වෙනුවට සියලුම වසම් තර්කනය ග්‍රහණය කර ගන්නා සේවා වස්තු සමූහයක් ඇත. මෙම සේවාවන් වසම් ආකෘතියට ඉහළින් ජීවත් වන අතර දත්ත සඳහා වසම් ආකෘතිය භාවිතා කරයි.
(...) වසම් වස්තුවක තිබිය යුතු තර්කනය වන්නේ වසම් තර්කනය - වලංගු කිරීම්, ගණනය කිරීම්, ව්‍යාපාර නීති - ඔබ එය කැඳවීමට කැමති ඕනෑම දෙයක්.
මට නම්, තත්වය හරියටම මෙය බව පෙනේ: වස්තුවක දත්ත හැසිරවීමට මම යෝජනා කළේ එම පන්තිය තුළම ක්‍රමවේදයන් හඳුන්වා දීමෙනි. කෙසේ වෙතත්, මෙය ලබා දී ඇති එක් ක්‍රමයක් විය යුතු බව මට වැටහී ඇති අතර, මෙම ක්රම භාවිතා කරන ආකාරය (නිධිය භාවිතා කරමින්) සමඟ බොහෝ දුරට සම්බන්ධ විය හැකිය.
මම ද එම ලිපිය (පහත බලන්න), එම සේවා ස්ථරය තුළ වඩාත් සලකන බව හැඟීමක් තිබ්බා ව්යාජය නියෝජිතයින් සත්ය වැඩ දැඩි ස්ථරය වඩා, යටින් ආකෘතිය කිරීමට කටයුතු කරන.
යෙදුම් ස්ථරය [සේවා ස්ථරය සඳහා ඔහුගේ නම]: මෘදුකාංගය විසින් කළ යුතු කාර්යයන් නිර්වචනය කරන අතර ගැටළු නිරාකරණය සඳහා ප්‍රකාශන වසම් වස්තු යොමු කරයි. මෙම ස්තරය වගකිව යුතු කාර්යයන් ව්‍යාපාරයට අර්ථවත් හෝ වෙනත් පද්ධතිවල යෙදුම් ස්ථර සමඟ අන්තර් ක්රියා කිරීමට අවශ්ය වේ. මෙම ස්තරය සිහින්ව තබා ඇත. එහි ව්යාපාරික නීති හෝ දැනුම අඩංගු නොවේ, නමුත් කාර්යයන් සම්බන්ධීකරණය කිරීම සහ නියෝජිතයින් පමණක් ඊළඟ ස්ථරයේ ඩොමේන් වස්තූන්ගේ සහයෝගීතාවයට වැඩ කරයි. එයට ව්යාපාරික තත්වය පිළිබිඹු කරන රාජ්‍යයක් නොමැත, නමුත් පරිශීලකයාට හෝ වැඩසටහනට යම් කාර්යයක ප්‍රගතිය පිළිබිඹු කරන රාජ්‍යයක් එයට තිබිය හැකිය.
සේවා අතුරුමුහුණත්. සියලුම අභ්‍යන්තර පණිවිඩ යවන සේවා අතුරු මුහුණතක් සේවා විසින් නිරාවරණය කරයි. සේවා අතුරුමුහුණතක් යෙදුමේ ක්‍රියාත්මක කර ඇති ව්යාපාරික තර්කනය (සාමාන්‍යයෙන් ව්‍යාපාර ස්ථරයේ තර්කනය) අනාගත පාරිභෝගිකයින්ට නිරාවරණය කරන මුහුණතක් ලෙස ඔබට සිතිය හැකිය.
හා මෙහි :
සේවා ස්ථරය කිසිදු යෙදුමක් හෝ ව්‍යාපාර තර්කනයකින් තොර විය යුතු අතර මූලික වශයෙන් අවධානය යොමු කළ යුත්තේ කරුණු කිහිපයක් කෙරෙහි ය. එය ව්‍යාපාර ස්ථර ඇමතුම් එතීම, ඔබේ සේවාදායකයින්ට තේරුම් ගත හැකි පොදු භාෂාවෙන් ඔබේ වසම පරිවර්තනය කිරීම සහ සේවාදායකයා සහ ඉල්ලුම් කරන සේවාදායකයා අතර සන්නිවේදන මාධ්‍යය හැසිරවිය යුතුය.
සේවා ස්ථරය ගැන කතා කරන වෙනත් සම්පත් වලට මෙය බරපතල වෙනසකි :
සේවා ස්ථරය එකම ගනුදෙනුවකට අයත් ක්‍රියාවන් සමඟ වැඩ කරන ඒකක වන ක්රම සහිත පන්ති වලින් සමන්විත විය යුතුය.
නැතහොත් මා දැනටමත් සම්බන්ධ කර ඇති ප්‍රශ්නයකට දෙවන පිළිතුර :
යම් අවස්ථාවක දී, ඔබේ යෙදුමට යම් ව්‍යාපාර තර්කනයක් අවශ්ය වනු ඇත. එසේම, අයහපත් හෝ අක්‍රීය දෙයක් ඉල්ලා නැති බව තහවුරු කර ගැනීම සඳහා ආදානය වලංගු කිරීමට ඔබට අවශ්ය විය හැකිය. මෙම තර්කනය ඔබේ සේවා ස්ථරයට අයත් වේ.
"විසඳුමක්"?
මෙම පිළිතුරේ ඇති මාර්ගෝපදේශ අනුගමනය කරමින් , සේවා ස්ථරයක් භාවිතා කරන පහත දැක්වෙන ප්‍රවේශය මා විසින් ඉදිරිපත් කරන ලදී:
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;
}
}
නිගමනය
සියල්ලම එකට මෙහි බොහෝ වෙනස් වී නැත: පාලකයේ කේතය සේවා ස්ථරයට මාරු වී ඇත (එය හොඳ දෙයකි, එබැවින් මෙම ප්‍රවේශයට උඩු යටිකුරු කිරීමක් ඇත). කෙසේ වෙතත් මෙය මගේ මුල් පිළිතුර සමඟ කිසිදු සම්බන්ධයක් ඇති බවක් නොපෙනේ.
සැලසුම් රටා මාර්ගෝපදේශ බව මම තේරුම් ගතිමි, හැකි සෑම විටම ක්‍රියාත්මක කළ යුතු නීති රීති නොවේ. එහෙත් සේවා ස්ථරය හා එය සලකා බැලිය යුතු ආකාරය පිළිබඳ නිශ්චිත පැහැදිලි කිරීමක් මට හමු වී නැත.
එය හුදෙක් පාලකයෙන් තර්කනය උකහා ගෙන ඒ වෙනුවට සේවාවක් තුළට දැමීමේ මාධ්‍යයක්ද?
එය පාලකය සහ වසම අතර ගිවිසුමක් ඇති කළ යුතුද?
වසම සහ සේවා ස්ථරය අතර තට්ටුවක් තිබිය යුතුද?
අවසාන වශයෙන් නොව අවම වශයෙන්: මුල් අදහස් දැක්වීම අනුගමනය කිරීම
ව්‍යාපාර තර්කනය සැබවින්ම සේවාවක තිබිය යුතුය. ආකෘතියක නොවේ.
මේක හරිද?
- ආකෘතිය වෙනුවට සේවාවක් තුළ මගේ ව්‍යාපාර තර්කනය හඳුන්වා දෙන්නේ කෙසේද?
