ආයතන රාමුව සමඟ නිධිය රටාව භාවිතා නොකළ යුත්තේ ඇයි?

රැකියා සම්මුඛ සාකච්ඡාවකදී, ආයතන රාමුව වැනි ORM සමඟ වැඩ කිරීමට නිධිය රටාව හොඳ රටාවක් නොවන්නේ මන්දැයි පැහැදිලි කිරීමට මාගෙන් විමසන ලදි. මෙය එසේ වන්නේ ඇයි?

ආයතන රාමුව සමඟ වැඩ නොකිරීමට නිධිය රටාවට කිසිදු හේතුවක් මා දකින්නේ නැත. නිධිය රටාව යනු ඔබේ දත්ත ප්‍රවේශ ස්තරය මත ඔබ තැබූ වියුක්ත ස්ථරයකි. ඔබේ දත්ත ප්‍රවේශ ස්ථරය පිරිසිදු ADO.NET ගබඩා කර ඇති ක්‍රියා පටිපාටිවල සිට ආයතන රාමුව හෝ XML ගොනුවක් විය හැකිය.

විවිධ පද්ධති වලින් (දත්ත සමුදාය / එක්ස්එම්එල් / වෙබ් සේවාව) දත්ත ඔබ සතුව ඇති විශාල පද්ධතිවල, වියුක්ත ස්ථරයක් තිබීම හොඳය. මෙම තත්වය තුළ නිධිය රටාව හොඳින් ක්‍රියාත්මක වේ. තිරය ​​පිටුපස සිදුවන දේ සැඟවීමට ආයතන රාමුව ප්‍රමාණවත් වියුක්තයක් යැයි මම විශ්වාස නොකරමි.

මගේ දත්ත ප්‍රවේශ ප්‍රවේශ ස්ථර ක්‍රමය ලෙස මම ආයතන රාමුව සමඟ නිධිය රටාව භාවිතා කර ඇති අතර තවමත් ගැටලුවකට මුහුණ දී නොමැත.

DbContextනිධිය සමඟ වියුක්ත කිරීමේ තවත් වාසියක් වන්නේ ඒකක-පරීක්ෂණ හැකියාවයි . ඔබේ IRepositoryඅතුරුමුහුණත ක්‍රියාත්මක කිරීම් 2 ක් ඇති අතර, එකක් (සැබෑ නිධිය) DbContextදත්ත සමුදාය සමඟ කතා කිරීමට භාවිතා කරන අතර දෙවැන්න FakeRepositoryමතක මතක වස්තු / සමච්චල් කළ දත්ත ආපසු ලබා දිය හැකිය. මෙය ඔබගේ IRepositoryඒකකය පරීක්ෂා කළ හැකි වන අතර එමඟින් කේතයේ වෙනත් කොටස් භාවිතා කරයි IRepository.

public interface IRepository
{
  IEnumerable<CustomerDto> GetCustomers();
}
public EFRepository : IRepository
{
  private YourDbContext db;
  private EFRepository()
  {
    db = new YourDbContext();
  }
  public IEnumerable<CustomerDto> GetCustomers()
  {
    return db.Customers.Select(f=>new CustomerDto { Id=f.Id, Name =f.Name}).ToList();
  }
}
public MockRepository : IRepository
{
  public IEnumerable<CustomerDto> GetCustomers()
  {
    // to do : return a mock list of Customers
    // Or you may even use a mocking framework like Moq
  }
}

දැන් DI භාවිතා කරමින්, ඔබට ක්‍රියාත්මක කිරීම ලැබේ

public class SomeService
{
  IRepository repo;
  public SomeService(IRepository repo)
  {
     this.repo = repo;
  }  
  public void SomeMethod()
  {
    //use this.repo as needed
  }    
}

ආයතන රාමුව සමඟ නිධිය රටාව භාවිතා නොකිරීමට ඇති හොඳම හේතුව කුමක්ද? ආයතන රාමුව දැනටමත් නිධිය රටාවක් ක්‍රියාත්මක කරයි. DbContextඔබේ UoW (වැඩ ඒකකය) වන අතර සෑම එකක්ම DbSetනිධිය වේ. මේ මත තවත් තට්ටුවක් ක්‍රියාත්මක කිරීම අතිරික්තයක් පමණක් නොව නඩත්තු කිරීම දුෂ්කර කරයි.

රටාවේ අරමුණ අවබෝධ කර නොගෙන මිනිසුන් රටා අනුගමනය කරයි. නිධිය රටාව සම්බන්ධයෙන් ගත් කල, අරමුණ වන්නේ පහත් මට්ටමේ දත්ත සමුදා විමසීමේ තර්කනය වියුක්ත කිරීමයි. ඔබේ කේතයේ ඇත්ත වශයෙන්ම SQL ප්‍රකාශ ලිවීමේ පැරණි දිනවල, නිධිය රටාව යනු ඔබේ කේත පදනම පුරා විසිරී ඇති තනි ක්‍රම වලින් එම SQL ගෙනයාමට සහ එය එක තැනක ස්ථානගත කිරීමටය. Entity Framework, NHibernate, වැනි ORM එකක් තිබීම මෙම කේත වියුක්ත කිරීම සඳහා ආදේශකයක් වන අතර එමඟින් රටාවේ අවශ්‍යතාවය ප්‍රතික්ෂේප කරයි.

කෙසේ වෙතත්, ඔබේ ORM මුදුනේ සාරාංශයක් නිර්මාණය කිරීම නරක අදහසක් නොවේ, UoW / repostitory තරම් සංකීර්ණ කිසිවක් නොවේ. මම සේවා රටාවක් සමඟ යන්නෙමි, එහිදී ඔබ ඔබේ යෙදුමට ආයතන රාමුව, එන්එච්බර්නේට් හෝ වෙබ් ඒපීඅයි වෙතින් දත්ත පැමිණෙන්නේ දැයි නොදැන හෝ සැලකිලිමත් නොවී භාවිතා කළ හැකි API එකක් සාදයි. ඔබේ යෙදුමට අවශ්‍ය දත්ත ආපසු ලබා දීම සඳහා ඔබ ඔබේ සේවා පන්තියට ක්‍රම එකතු කරන බැවින් මෙය වඩාත් සරල ය. ඔබ කළ යුතු යෙදුමක් ලියන්නේ නම්, උදාහරණයක් ලෙස, මේ සතියේ ලැබීමට නියමිත අයිතම නැවත ලබා දීම සඳහා ඔබට සේවා ඇමතුමක් තිබිය හැකි අතර තවමත් සම්පූර්ණ කර නොමැත. ඔබගේ සියලු යෙදුම දන්නා දෙය නම් එයට මෙම තොරතුරු අවශ්‍ය නම් එය එම ක්‍රමය ලෙස හඳුන්වන බවයි. එම ක්‍රමවේදය තුළ සහ පොදුවේ ඔබේ සේවාවේදී, ඔබ ආයතන රාමුව හෝ ඔබ භාවිතා කරන වෙනත් ඕනෑම දෙයක් සමඟ අන්තර් ක්‍රියා කරයි. පසුව, ඔබ ORM මාරු කිරීමට හෝ වෙබ් API එකකින් තොරතුරු අදින්නට තීරණය කරන්නේ නම්,

එය නිධිය රටාව භාවිතා කිරීම සඳහා විභව තර්කයක් සේ පෙනෙන්නට පුළුවන, නමුත් මෙහි ඇති ප්‍රධාන වෙනස වන්නේ සේවාවක් තුනී ස්ථරයක් වන අතර ඔබ දිගින් දිගටම විමසන දෙයකට වඩා සම්පූර්ණයෙන්ම පිළිස්සූ දත්ත ආපසු ලබා දීමට යොමු වීමයි. නිධිය.

අයින්ඩේ රහියන්ගෙන් ලබාගත් එක් කරුණක් මෙන්න: ගෘහ නිර්මාණ ශිල්පය විනාශයේ වළේ: නිධිය වියුක්ත ස්ථරයේ නපුර

ඔහුගේ නිගමනයට මා එකඟ දැයි මට තවමත් විශ්වාස නැත. එය අල්ලා ගැනීම -22 - එක් අතකින්, විමසුම්-විශේෂිත දත්ත ලබා ගැනීමේ ක්‍රම සමඟ මගේ ඊඑෆ් සන්දර්භය ටයිප්-විශේෂිත ගබඩාවල ඔතා තිබේ නම්, ඇත්ත වශයෙන්ම මට මගේ කේතය (වර්ග කිරීම) පරීක්ෂා කිරීමට හැකියාවක් ඇත, එය එන්ටිටි සමඟ පාහේ කළ නොහැකි ය රාමුව පමණක්. අනෙක් අතට, සබඳතා පොහොසත් විමසීම් සහ අර්ථකථන නඩත්තු කිරීමේ හැකියාව මට අහිමි වේ (නමුත් මට එම අංගයන් වෙත පූර්ණ ප්‍රවේශයක් ඇති විට පවා මට දැනෙන්නේ මම EF හෝ වෙනත් වෙනත් ORM වටා බිත්තර කටු මත ඇවිදිමින් සිටින බවයි. , එය කිසිසේත් ක්‍රියාත්මක කළ නොහැකි හෝ ක්‍රියාත්මක නොවිය හැකි ක්‍රමවේදයන් මා නොදන්නා හෙයින්, එය සංචාලන දේපල එකතුවකට මා එකතු කිරීම නිර්මාණයක් හෝ හුදෙක් සංගමයක් ලෙස අර්ථ දක්වනු ඇත්ද, එය කම්මැලි හෝ උනන්දුවෙන් පැටවීමට යන්නේද නැතහොත් කිසිසේත් පටවන්නේ නැත. පෙරනිමි, ආදිය. ඉතින් සමහර විට මෙය වඩා හොඳ විය හැකිය. ශුන්‍ය-සම්බාධනය වස්තු-සම්බන්ධතා "සිතියම්ගත කිරීම" යනු මිථ්‍යා ජීවීන්ගේ දෙයක් විය හැකිය - සමහර විට නවතම රාමු නිකුතුව "මැජික් යුනිකෝන්" ලෙස සංකේතවත් කරන ලද්දේ ඒ නිසා විය හැකිය).

කෙසේ වෙතත්, විමසුම්-විශේෂිත දත්ත ලබා ගැනීමේ ක්‍රම මගින් ඔබේ ආයතන ලබා ගැනීම යන්නෙන් අදහස් වන්නේ ඔබේ ඒකක පරීක්ෂණ දැන් අත්‍යවශ්‍යයෙන්ම සුදු පෙට්ටි පරීක්ෂණ වන අතර මේ සම්බන්ධයෙන් ඔබට වෙනත් විකල්පයක් නොමැති හෙයිනි, පරීක්ෂණයට භාජනය වන ඒකකය යන්නේ කුමන නිධිය ක්‍රමයටද යන්න ඔබ කල්තියා දැන සිටිය යුතුය. එය සමච්චල් කිරීම සඳහා අමතන්න. ඔබ තවමත් ඒකාබද්ධ පරීක්ෂණ ලියන්නේ නැත්නම්, ඔබ තවමත් සත්‍ය වශයෙන්ම විමසීම් පරීක්‍ෂා නොකරයි.

මේවා සංකීර්ණ විසඳුමක් අවශ්‍ය සංකීර්ණ ගැටළු ය. ඔබේ සියලු ආයතන ඒවා අතර කිසිදු සම්බන්ධයක් නොමැති වෙනම වර්ගයක් යැයි මවා පාමින් ඒවා නිවැරදි කළ නොහැක. හොඳයි ඔබට පුළුවන් , නමුත් එය උරා බොනවා.

යාවත්කාලීන කිරීම: මම භාවිතා යම් සාර්ථකත්වයක් ඇති මහත් වෑයමක් සලක් රාමුව සැපයුම්කරු අමතන්න. උත්සාහය යනු මතකයේ ඇති සැපයුම්කරුවෙකි (විවෘත මූලාශ්‍රය) එය සත්‍ය දත්ත ගබඩාවකට එරෙහිව ඔබ භාවිතා කරන ආකාරයටම පරීක්ෂණ වලදී EF භාවිතා කිරීමට ඉඩ සලසයි. මෙම ව්‍යාපෘතියේ ඇති සියලුම පරීක්ෂණ මාරුවීම ගැන මම සලකා බලමි. මෙම සැපයුම්කරු භාවිතා කිරීමට මම කටයුතු කරමි. මා මෙතෙක් සොයාගෙන ඇති එකම විසඳුම වන්නේ මා කලින් කතා කළ සියලු ගැටලු විසඳීමයි. මතකයේ ඇති දත්ත සමුදාය නිර්මාණය කරන විට මගේ පරීක්ෂණ ආරම්භ කිරීමේදී සුළු ප්‍රමාදයක් ඇති එකම දෙය (එය මෙය කිරීමට NMemory නම් තවත් පැකේජයක් භාවිතා කරයි), නමුත් මෙය සැබෑ ගැටළුවක් ලෙස මා දකින්නේ නැත. පරීක්ෂා කිරීම සඳහා උත්සාහය (SQL CE හා එදිරිව) භාවිතා කිරීම ගැන කතා කරන කේත ව්‍යාපෘති ලිපියක් ඇත.

ඔබ බොහෝ විට එසේ කිරීමට හේතුව එය ටිකක් අතිරික්ත වීමයි. ආයතන රාමුව මඟින් ඔබට කේතීකරණ හා ක්‍රියාකාරී වාසි රාශියක් ලබා දෙයි, ඒ නිසා ඔබ එය භාවිතා කරයි, ඔබ එය රැගෙන නිධිය රටාවකට ඔතා එම වාසි ඉවතට විසි කරන්නේ නම්, ඔබ වෙනත් දත්ත ප්‍රවේශ ප්‍රවේශයක් භාවිතා කරයි.

න්‍යාය අනුව, දත්ත සමුදා සම්බන්ධතා තර්කනය වඩාත් පහසුවෙන් නැවත භාවිතා කළ හැකි වන පරිදි සංයුක්ත කිරීම අර්ථවත් යැයි මම සිතමි, නමුත් පහත සබැඳිය තර්ක කරන පරිදි, අපගේ නූතන රාමු මූලිකවම මේ ගැන සැලකිලිමත් වේ.

නිධිය රටාව නැවත සලකා බැලීම

නිධිය රටාව භාවිතා කිරීමට ඉතා හොඳ හේතුවක් වන්නේ ඔබේ ව්‍යාපාර තර්කනය සහ / හෝ ඔබේ UI System.Data.Entity වෙතින් වෙන් කිරීමට ඉඩ දීමයි. ව්‍යාජ හෝ විහිළු භාවිතා කිරීමට ඉඩ දීමෙන් ඒකක පරීක්ෂණයේ සැබෑ ප්‍රතිලාභ ඇතුළුව මෙයට බොහෝ වාසි ඇත.

අයි.ඕ.සී බහාලුමක් එක් වර්ගයකට නව () ඉහළ නිධි (උදාහරණයක් ලෙස පරිශීලක ගබඩාවක් සහ ඩී.බී.සී.කොන්ටෙක්ස්ට් වෙතින් තමන්ගේම අයිඩීබීසෙට් යනුවෙන් හඳුන්වන කණ්ඩායම් නිධිය නිදසුනක්), සමහර විට ඉල්ලීමකට විවිධ සන්දර්භයන් ඇති කළ හැකි විට, අනුපිටපත් නමුත් වෙනස් ආයතන රාමුවක් සමඟ අපට ගැටලු තිබේ. (MVC / වෙබ් සන්දර්භය තුළ).

බොහෝ විට එය තවමත් ක්‍රියාත්මක වේ, නමුත් ඔබ ඊට ඉහළින් සේවා තට්ටුවක් එක් කළ විට සහ එම සේවාවන් එක් සන්දර්භයක් සමඟ නිර්මාණය කරන ලද වස්තූන් වෙනත් සන්දර්භයක නව වස්තුවකට ළමා එකතු කිරීමක් ලෙස නිවැරදිව සම්බන්ධ වනු ඇතැයි උපකල්පනය කළ විට, එය සමහර විට අසමත් වන අතර සමහර විට එසේ නොවේ. t වල වේගය අනුව.

කුඩා ව්‍යාපෘතියක් සඳහා නිධිය රටාවක් අත්හදා බැලීමෙන් පසු එය භාවිතා නොකරන ලෙස මම තරයේ අවවාද කරමි. එය ඔබේ පද්ධතිය අවුල් කරන නිසා නොව, දත්ත සමච්චල් කිරීම නපුරු සිහිනයක් නිසා නොව, ඔබේ පරීක්ෂණය නිෂ් less ල වන නිසා නොවේ !!

දත්ත සමච්චලයට ලක් කිරීම මඟින් ඔබට ශීර්ෂයන් නොමැතිව විස්තර එක් කිරීමට, දත්ත සමුදායේ සීමාවන් උල්ලං that නය කරන වාර්තා එකතු කිරීමට සහ දත්ත සමුදාය ඉවත් කිරීම ප්‍රතික්ෂේප කරන ආයතන ඉවත් කිරීමට ඉඩ ලබා දේ. තථ්‍ය ලෝකයේ තනි යාවත්කාලීනයක් බහු වගු, ල logs ු-සටහන්, ඉතිහාසය, සාරාංශ යනාදිය මෙන්ම අවසාන වරට වෙනස් කරන ලද දින ක්ෂේත්‍රය, ස්වයංක්‍රීයව ජනනය කරන ලද යතුරු, ගණනය කළ ක්ෂේත්‍ර වැනි තීරු වලට බලපායි.

කෙටියෙන් ඔබේ දත්ත තාත්වික දත්ත ගබඩාවේ ධාවනය කිරීමෙන් ඔබට සැබෑ ප්‍රති results ල ලබා ගත හැකි අතර ඔබේ සේවාවන් සහ අතුරුමුහුණත් පමණක් නොව දත්ත සමුදායේ හැසිරීමද පරීක්ෂා කළ හැකිය. ඔබගේ ගබඩා කර ඇති ක්‍රියා පටිපාටීන් දත්ත සමඟ නිවැරදි දේ කරයිද, අපේක්ෂිත ප්‍රති result ලය ලබා දෙයිද, නැතහොත් මකා දැමීමට ඔබ එවූ වාර්තාව සැබවින්ම මකා දමා ඇත්දැයි ඔබට පරීක්ෂා කළ හැකිය! ගබඩා කරන ලද ක්‍රියාපටිපාටියෙන් දෝෂ මතු කිරීමට අමතක වීම සහ එවැනි අවස්ථා දහස් ගණනක් වැනි ගැටළු ද එවැනි පරීක්ෂණ මගින් හෙළි කළ හැකිය.

මා සිතන්නේ, මෙතෙක් මා කියවා ඇති ඕනෑම ලිපියකට වඩා ආයතන රාමුව නිධිය රටාව ක්‍රියාත්මක කරන අතර එය ඔවුන් ඉටු කිරීමට උත්සාහ කරන දෙයට වඩා බොහෝ සෙයින් වැඩි ය.

අප එක්ස්බේස්, ඇඩෝඑක්ස් සහ ඇඩෝ.නෙට් භාවිතා කළ දිනවල නිධිය වඩාත් හොඳ පුරුද්දක් විය. (නිධිය හරහා නිධිය)

අවසාන වශයෙන් මම සිතන්නේ බොහෝ අය නිධිය රටාව ඉගෙන ගැනීමට සහ ක්‍රියාත්මක කිරීමට බොහෝ කාලයක් ආයෝජනය කරන අතර ඔවුන් එයට ඉඩ දීම ප්‍රතික්ෂේප කරති. බොහෝ විට තමන් කාලය නාස්ති නොකළ බව තමන්ටම ඔප්පු කර ගැනීමට.

සංක්‍රමණ හේතුවෙන් එය සිදුවී ඇත: සම්බන්ධක නූල web.config හි පිහිටා ඇති බැවින්, සංක්‍රමණ වැඩට ගැනීමට නොහැකි ය. නමුත්, DbContext නිධිය ස්ථරයේ වාසය කරයි. IDbContextFactory හට දත්ත සමුදායට වින්‍යාස කිරීමේ නූලක් තිබිය යුතුය .නමුත් සංක්‍රමණිකයින්ට web.config වෙතින් සම්බන්ධතා නූල ලබා ගත හැකි ක්‍රමයක් නොමැත.

අවට වැඩ ඇතත් මේ සඳහා පිරිසිදු විසඳුමක් මට තවම හමු වී නැත!