MediatR අද කාලයේ .NET ප්රොජෙට්ස් වල සාමාන්යම කොටසක් වුණා. නව ව්යාපෘතියක් ආරම්භ කරන විට පළමු සතියේම එකතු කර, පසුගිය සියලු ඉල්ලීම් ඒකේ හෑන්ඩලරයකින් පසු කරයි. එය "පිරිසිදු" කියලා හෝ "අපි හැමවිටම මේක කරමු" කියලා හේතුවක් දෙනවා. එහෙමත් නැතිනම්, එය පුරුද්දක් පමණයි.
මෙම ලිපියේ ලේඛකයා MediatR එකේ ප්රධාන වාසි දෙකක් කියලා පෙන්වයි: **decoupling** සහ **pipeline behaviors**. Decoupling කියන්නේ, controller එකක් service එකට සෘජුවම ඇමතුමක් නොකර, request object එකක් යවා, ඒක හෑන්ඩලරයක් ගන්නා විදිය. Pipeline කියන්නේ, logging, validation, transaction වගේ cross‑cutting concerns එකම තැනින් එක් කරන්න හැකි වීම.
එහෙත්, වාසි වලට වඩා ගාස්තු වැඩි වෙන්න පුළුවන්. MediatR භාවිතා කරන විට, F12 එකෙන් method එකක් සොයන බද්ධතාවය අහිමිවෙයි; Send() කියලා library එකේ ඇතුළත යනවා, හෑන්ඩලරය හොයන්න request type නාමයෙන්ම සෙවීමට වෙයි. එක request එකට command class, handler class, registration, Send() call වැනි කොටස් හතරක් අවශ්ය වෙනවා. සාමාන්ය “cancel order” වගේ සරල ක්රියාවකට මේ වගේ වැඩ බරක් නොවෙයි.
ශ්රී ලංකාවට ඇති වැදගත්කම
ශ්රී ලංකාවේ බොහෝ සමාගම් .NET තාක්ෂණය භාවිතා කරන අතර, නව සංවර්ධකයින්ට MediatR පුරුද්ද ඉතා පහසුවෙන් පතනවා. එය හොඳම වාසියක් වන්නේ, විශාල කණ්ඩායමක් තුළ සමාන code structure එකක් රැකගත හැකි වීමයි. එය නිවැරදිව CQRS ආකෘතියක් සමඟ යෙදීමේදී, commands හා queries වෙන වෙනම හෑන්ඩලරයකින් පාලනය කිරීමේදී, architecture එක තදබල වේ. නමුත්, සාමාන්ය CRUD API එකකට එය අත්යවශ්ය නොවේ; අමතර layers නිසා maintainability අඩු වෙයි, ඉගෙනුම් වක්රය දිගු කරයි. ශ්රී ලංකාවේ startups සහ SMEs සඳහා, MediatR භාවිතය තේරීම් කරගැනීමට හෝ අඩු පිරිවැයෙන් වැඩ කිරීමට අවශ්ය තැනක් තේරුම් ගත යුතුයි.
අවසානයේ, MediatR එක හොඳ library එකක්, නමුත් එය “default” ලෙස පළමු දිනයේම එකතු කිරීමේ පුරුද්ද වැරදි තීරණයක් විය හැක. ඔබේ ව්යාපෘතියේ අවශ්යතා අනුව, pipeline behaviors සඳහා middleware, filters, validation libraries භාවිතා කිරීම පිරිසිදු හා කාර්යක්ෂම විය හැක.
