ඉහළ තදබදය සහිත වෙබ් අඩවි සඳහා ආයතන රාමුව සුදුසු ද?

තත්පරයට පහර 1000 ක් සහිත පොදු වෙබ් අඩවියක් සඳහා ආයතන රාමුව 4 හොඳ විසඳුමක් ද?

මගේ අවබෝධය අනුව ඊඑෆ් යනු බොහෝ දුරට කුඩා හෝ අන්තර් ජාල වෙබ් අඩවි සඳහා ශක්‍ය විසඳුමක් වන නමුත් ජනප්‍රිය ප්‍රජා වෙබ් අඩවියක් වැනි දෙයක් සඳහා පහසුවෙන් පරිමාණයට නොයනු ඇත (මම දන්නවා එස්.ඕ. ..)

දැන් මම පිරිසිදු ADO.NET ප්‍රවේශයක් හෝ EF4 තෝරා ගැනීමේ සන්ධිස්ථානයක සිටිමි. EF සමඟ වැඩිදියුණු කළ සංවර්ධක produc ලදායිතාව ADO.NET හි (නැතිවූ කාර්ය සාධනය සමඟ) නැතිවූ කාර්ය සාධනය සහ කැටිති ප්‍රවේශය වටී යැයි ඔබ සිතනවාද? ඉහළ ගමනාගමන වෙබ් අඩවියකට ඇතිවිය හැකි බරපතල ගැටළු තිබේ නම්, එය EF භාවිතා කළේද?

ඔයාට කලින්ම ස්තූතියි.

එය ඔබ කොතරම් වියුක්තීකරණය මත ටිකක් රඳා පවතී අවශ්ය . සෑම දෙයක්ම සම්මුතියකි; උදාහරණයක් ලෙස, EF හා NHibernate රසවත් හා විසිතුරු ආකෘති ඇති දත්ත නියෝජනය සඳහා විශාල නම්යශීලිත්වය හඳුන්වා - එහෙත් එහි ප්රතිඵලයක් ලෙස ඔවුන් කරන්නේ පොදු කාර්ය එක් කරන්න. සැලකිය යුතු පොදු කාර්ය.

ඔබ නැති නම් අවශ්ය දත්ත සමුදාය සපයන්නන්, හා විවිධ අනුව-සේවාදායක පිරිසැලසුම් අතර මාරු වීමට හැකි විය, සහ ඔබගේ දත්ත මූලික වශයෙන් නම් කියවීමට , සහ ඔබ EF එකම ආදර්ශ භාවිතා කිරීමට හැකි විය යුතු නැහැ නම්, SSRS , ADO.NET දත්ත සේවා යනාදිය - එවිට ඔබේ ප්‍රධාන මිනුම ලෙස නිරපේක්ෂ කාර්ය සාධනය අවශ්‍ය නම් ඔබට ඩැපර් දෙස බැලීමට වඩා නරක දෙයක් කළ හැකිය . LINQ-to-SQL සහ EF යන දෙකම මත පදනම් වූ අපගේ පරීක්ෂණ වලදී, අමු කියවීමේ කාර්ය සාධනය අනුව EF සැලකිය යුතු ලෙස මන්දගාමී බව අපට පෙනී යන්නේ , වියුක්ත ස්ථර (ගබඩා ආකෘතිය ආදිය අතර) සහ ද්‍රව්‍යකරණය නිසා විය හැකිය.

SO හි දී, අපි අමු ක්‍රියාකාරිත්වය පිළිබඳ උමතු සහගත වන අතර, වේගය ලබා ගැනීම සඳහා යම් වියුක්තයක් අහිමි වීමේ සංවර්ධන පහර ගැනීමට අපි සතුටු වෙමු. එනිසා දත්ත සමුදාය විමසීමේ අපගේ මූලික මෙවලම ඩැපර් ය . මෙය අපගේ පෙර පැවති LINQ-to-SQL ආකෘතිය භාවිතා කිරීමට පවා ඉඩ දෙයි, නමුත් සරලවම: එය වේගයෙන් ගොඩ ගසයි. කාර්ය සාධන පරීක්ෂණ වලදී, එය අත්‍යවශ්‍යයෙන්ම සියලුම ADO.NET කේතය (පරාමිතීන්, දත්ත කියවන්නා යනාදිය) අතින් ලිවීම හා සමාන කාර්ය සාධනයකි, නමුත් තීරු නමක් වැරදියට ලබා ගැනීමේ අවදානමකින් තොරව. කෙසේ වෙතත්, එය SQL මත පදනම් වූවකි (ඔබ තෝරාගත් වස නම් SPROCs භාවිතා කිරීම සතුටට කරුණකි). මෙම වාසිය නැති බවයි කිසිදු සම්බන්ධ අතිරේක සැකසුම්, නමුත් එය වේ කරන SQL වැනි ජනයා සඳහා පද්ධතියක්. මා සලකන්නේ: නරක දෙයක් නොවේ!

උදාහරණයක් ලෙස සාමාන්‍ය විමසුමක් විය හැක්කේ:

int customerId = ...
var orders = connection.Query<Order>(
    "select * from Orders where CustomerId = @customerId ",
    new { customerId }).ToList();

එය පහසු, එන්නත්-ආරක්ෂිත යනාදියයි - නමුත් ටොන් ගණනක් දත්ත කියවන්නා නොමැතිව. සංකීර්ණ ව්‍යුහයන් පැටවීම සඳහා තිරස් හා සිරස් කොටස් දෙකම හැසිරවිය හැකි නමුත්, එය කම්මැලි පැටවීමට සහාය නොදක්වන බව සලකන්න (නමුත්: අපි ඉතා පැහැදිලිව පැටවීමේ විශාල පංකා - විස්මයන් අඩු).

සටහන මෙම පිළිතුර මම කියන්නේ නැහැ EF බව මා නොවේ ඉහළ පරිමාවක් කටයුතු සඳහා සුදුසු; සරලව: ඩැපර් ඒ සඳහා සුදුසු බව මම දනිමි .

"මම කුමන ORM භාවිතා කළ යුතුද" යන ප්‍රශ්නය සැබවින්ම ඉලක්ක කරන්නේ විශාල පරිමාණයේ යෙදුමක සමස්ත දත්ත ප්‍රවේශ ක්‍රමෝපාය සහ කාර්ය සාධනය ප්‍රශස්තිකරණය කිරීමේදී විශාල අයිස් කුට්ටියක ඉඟියයි.

පහත සඳහන් සියලු දේ ( දළ වශයෙන් වැදගත්කම අනුව) ප්‍රති put ල කෙරෙහි බලපානු ඇති අතර, ඒවා සියල්ලම එහි ඇති ප්‍රධාන ORM රාමු බොහෝමයක් (සමහර විට විවිධ ආකාරවලින්) හසුරුවනු ලැබේ:

1. දත්ත සමුදාය සැලසුම් කිරීම සහ නඩත්තු කිරීම

   මෙය පුළුල් ආන්තිකයකින් දත්ත පදනම් කරගත් යෙදුමක හෝ වෙබ් අඩවියක ප්‍රති put ල තීරණය කිරීමේ වැදගත්ම නිර්ණායකය වන අතර බොහෝ විට එය ක්‍රමලේඛකයින් විසින් නොසලකා හරිනු ලැබේ.

   ඔබ නිසි සාමාන්‍යකරණ ක්‍රමවේදයන් භාවිතා නොකරන්නේ නම්, ඔබේ වෙබ් අඩවිය විනාශ වනු ඇත. ඔබට ප්‍රාථමික යතුරු නොමැති නම්, සෑම විමසුමක්ම පාහේ සුනඛ-මන්දගාමී වනු ඇත. කිසිදු හේතුවක් නොමැතිව යතුරු-අගය යුගල (AKA Entity-Attribute-Value) සඳහා වගු භාවිතා කිරීම වැනි සුප්‍රසිද්ධ ප්‍රති-රටා ඔබ භාවිතා කරන්නේ නම්, ඔබ භෞතික කියවීම් සහ ලිවීම් ගණන පුපුරා යයි.

   පිටු සම්පීඩනය, FILESTREAMගබඩා කිරීම (ද්විමය දත්ත සඳහා), SPARSEතීරු, hierarchyidධූරාවලිය සඳහා යනාදිය වැනි දත්ත සමුදාය ඔබට ලබා දෙන විශේෂාංග වලින් ඔබ ප්‍රයෝජන නොගන්නේ නම් (සියලුම SQL සේවාදායක උදාහරණ), එවිට ඔබට ආසන්නයේ කොතැනකවත් නොපෙනේ. ඔබට දැකිය හැකි කාර්ය සාධනය .

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

2. ඊජර් එදිරිව කම්මැලි පැටවීම

   බොහෝ ORMs සබඳතා සඳහා කම්මැලි පැටවීම නමින් තාක්ෂණයක් භාවිතා කළ අතර එයින් අදහස් කරන්නේ පෙරනිමියෙන් එය වරකට එක් ආයතනයක් (වගු පේළිය) පටවනු ඇති අතර දත්ත සමුදායට සම්බන්ධිත එකක් හෝ කිහිපයක් පැටවීමට අවශ්‍ය සෑම අවස්ථාවකම එය වටා ගමන් කිරීමයි. යතුර) පේළි.

   මෙය හොඳ හෝ නරක දෙයක් නොවේ, එය රඳා පවතින්නේ ඇත්ත වශයෙන්ම දත්ත සමඟ කුමක් කිරීමට යන්නේද යන්න සහ ඔබ කොපමණ ඉදිරියෙන් සිටිනවාද යන්න මතය. සමහර විට කම්මැලි පැටවීම නියත වශයෙන්ම නිවැරදි දෙයයි. නිදසුනක් ලෙස, NHibernate කිසිසේත්ම කිසිවක් විමසීමට අකමැති විය හැකි අතර විශේෂිත හැඳුනුම්පතක් සඳහා ප්‍රොක්සියක් ජනනය කරයි . ඔබට අවශ්‍ය වන්නේ හැඳුනුම්පත පමණක් නම්, එය තවත් ඉල්ලිය යුත්තේ ඇයි? අනෙක් අතට, ඔබ 3 මට්ටමේ ධූරාවලියක් තුළ සෑම මූලද්‍රව්‍යයකම ගසක් මුද්‍රණය කිරීමට උත්සාහ කරන්නේ නම්, කම්මැලි පැටවීම O (N²) මෙහෙයුමක් බවට පත්වන අතර එය කාර්ය සාධනය සඳහා අතිශයින්ම නරක ය.

   “පිරිසිදු SQL” (එනම් අමු ADO.NET විමසුම් / ගබඩා කළ ක්‍රියා පටිපාටි) භාවිතා කිරීමෙන් ලැබෙන එක් රසවත් වාසියක් නම්, ඕනෑම තිරයක් හෝ පිටුවක් ප්‍රදර්ශනය කිරීමට අවශ්‍ය දත්ත මොනවාද යන්න ගැන සිතා බැලීමට එය මූලිකවම බල කරයි. ORMs කම්මැළි පැටවීම ලක්ෂණ නැහැ වැළැක්වීම මේ දේ ඔබ, නමුත් ඔවුන් කරන්නේ ඔබ විය කිරීමේ අවස්ථා උදා කර දෙන ... හොඳින්, කම්මැලි , සහ අහම්බෙන් ඔබ ක්රියාත්මක විමසුම් සංඛ්යාව පුපුරා. එබැවින් ඔබ ඔබේ ORMs උනන්දුවෙන් පටවන විශේෂාංග තේරුම් ගත යුතු අතර ඕනෑම පිටු ඉල්ලීමක් සඳහා ඔබ සේවාදායකයට යවන විමසුම් ගණන ගැන නිතරම විමසිලිමත් වන්න.

3. හැඹිලිය

   සියලුම ප්‍රධාන ORMs පළමු මට්ටමේ හැඹිලියක් වන AKA “අනන්‍යතා හැඹිලිය” පවත්වා ගෙන යයි, එයින් අදහස් වන්නේ ඔබ එකම ආයතනයට එහි හැඳුනුම්පතෙන් දෙවරක් ඉල්ලුවහොත්, එයට දෙවන වටයේ සංචාරයක් අවශ්‍ය නොවන අතර (ඔබ ඔබේ දත්ත සමුදාය නිවැරදිව නිර්මාණය කර ඇත්නම් ) ඔබට සුභවාදී සමගාමී මුදල් භාවිතා කිරීමේ හැකියාව ලබා දෙයි.

   L1 හැඹිලිය L2S සහ EF වල ඉතා පාරදෘශ්‍ය ය, එය ක්‍රියාත්මක වන බව ඔබ විශ්වාස කළ යුතුය. NHibernate ඒ ගැන වඩාත් පැහැදිලිය ( Get/ Loadvs. Query/ QueryOver). කෙසේ වෙතත්, ඔබ හැකිතාක් හැඳුනුම්පතෙන් විමසීමට උත්සාහ කරන තාක් කල්, ඔබ මෙහි හොඳින් සිටිය යුතුය. බොහෝ අය L1 හැඹිලිය අමතක කර එකම හැඳුනුම්පත එහි හැඳුනුම්පත හැර වෙනත් දෙයක් (නැවත බැලීමේ ක්ෂේත්‍රයක්) නැවත නැවතත් බලයි. ඔබට මෙය කිරීමට අවශ්‍ය නම් අනාගතය බැලීම සඳහා ඔබ හැඳුනුම්පත හෝ මුළු ආයතනයම සුරැකිය යුතුය.

   මට්ටමේ 2 හැඹිලියක් ද ඇත ("විමසුම් හැඹිලිය"). NHibernate සතුව මෙම නිමැවුම ඇත. ලින්ක් සිට එස්.එල්.කේ සහ එන්ටිටි ෆ්‍රේම්වර්ක් විසින් විමසුම් සම්පාදනය කර ඇති අතර, එමඟින් විමසුම් ප්‍රකාශනය සම්පාදනය කිරීමෙන් යෙදුම් සේවාදායක පැටවීම තරමක් අඩු කිරීමට උපකාරී වේ, නමුත් එය දත්ත හැඹිලි නොකරයි. මයික්‍රොසොෆ්ට් මෙය දත්ත ප්‍රවේශ ප්‍රවේශයකට වඩා යෙදුමක් ලෙස සලකන බව පෙනේ, මෙය L2S සහ EF යන දෙඅංශයේම ප්‍රධාන දුර්වල ලක්ෂ්‍යයකි. එය "අමු" SQL හි දුර්වල ස්ථානයක් බව අමුතුවෙන් කිව යුතු නැත. NHibernate හැර වෙනත් ඕනෑම ORM සමඟ හොඳ කාර්ය සාධනයක් ලබා ගැනීම සඳහා, ඔබ ඔබේම හැඹිලි මුහුණත ක්‍රියාත්මක කළ යුතුය.

   EF4 සඳහා L2 හැඹිලි "දිගුවක්" ද ඇත, එය හරි , නමුත් ඇත්ත වශයෙන්ම යෙදුම් මට්ටමේ හැඹිලිය සඳහා තොග ආදේශකයක් නොවේ.

4. විමසුම් ගණන

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

   ඔබට එක පේළියක් පමණක් අවශ්‍ය වූ විට මුළු දත්ත ගබඩාවම විමසීමට මම දැන් නොකියමි. ඔබට අවශ්ය නම්, මම කියන වේ Customer, Address, Phone, CreditCard, හා Orderතනි පිටුවේ සේවය කිරීම පිණිස සියලු එම අවස්ථාවේ දී පේළි, ඔබ කළ යුතු ඉල්ලා ඔවුන් සඳහා ඇති එකම අවස්ථාවේ දී, එම එක් එක් විමසුම ක්රියාත්මක කරන්නේ නැහැ. සමහර විට එය ඊට වඩා නරක ය, එකම Customerවාර්තාව එකවර 5 වතාවක් විමසන කේතය ඔබට පෙනෙනු ඇත , පළමුව ලබා ගැනීමට Id, පසුව Name, පසුව EmailAddress, පසුව ... එය හාස්‍යජනක ලෙස අකාර්යක්ෂම වේ.

   සම්පූර්ණයෙන්ම වෙනස් දත්ත කට්ටල මත ක්‍රියාත්මක වන විමසුම් කිහිපයක් ක්‍රියාත්මක කිරීමට ඔබට අවශ්‍ය වුවද, සාමාන්‍යයෙන් ඒ සියල්ල තනි "ස්ක්‍රිප්ට්" එකක් ලෙස දත්ත සමුදායට යැවීම සහ එය බහු ප්‍රති result ල කට්ටල ලබා දීම වඩාත් කාර්යක්ෂම වේ. එය ඔබ සැලකිලිමත් වන පොදු කාර්යය මිස මුළු දත්ත ප්‍රමාණය නොවේ.

   මෙය සාමාන්‍ය බුද්ධියක් සේ පෙනෙන්නට තිබුණද, යෙදුමේ විවිධ කොටස්වල ක්‍රියාත්මක වන සියලුම විමසුම් පිළිබඳ තොරතුරු නැති කර ගැනීම බොහෝ විට පහසු ය; ඔබේ සාමාජිකත්ව සැපයුම්කරු පරිශීලක / භූමිකම් වගු විමසයි, ඔබේ ශීර්ෂ ක්‍රියාව සාප්පු කරත්තය විමසයි, ඔබේ මෙනු ක්‍රියාව අඩවි සිතියම් වගුව විමසයි, ඔබේ පැති තීරු ක්‍රියාව මඟින් විශේෂිත නිෂ්පාදන ලැයිස්තුව විමසයි, එවිට සමහර විට ඔබේ පිටුව වෙනම ස්වාධීන ප්‍රදේශ කිහිපයකට බෙදා ඇත. ඇණවුම් ඉතිහාසය, මෑතකදී බැලූ, කාණ්ඩ, සහ ඉන්වෙන්ටරි වගු වෙන වෙනම විමසන්න, ඔබ එය දැන ගැනීමට පෙර, ඔබ පිටුවට සේවය කිරීමට පටන් ගැනීමට පෙර විමසුම් 20 ක් ක්‍රියාත්මක කරයි. එය කාර්ය සාධනය මුළුමනින්ම විනාශ කරයි.

   සමහර රාමු - සහ මම මෙහි ප්‍රධාන වශයෙන් NHibernate ගැන සිතමින් සිටිමි - මේ ගැන ඇදහිය නොහැකි තරම් දක්ෂ වන අතර අනාගත විමසීම් භාවිතා කිරීමට ඔබට ඉඩ සලසයි, එමඟින් සම්පූර්ණ විමසුම් එකතු කර ඒවා සියල්ලම එකවර ක්‍රියාත්මක කිරීමට උත්සාහ කළ හැකිය. AFAIK, ඔබට ඕනෑම Microsoft තාක්ෂණයක් සමඟ මෙය කිරීමට අවශ්‍ය නම් ඔබ තනිවම සිටී; ඔබ එය ඔබගේ යෙදුම් තර්කනයට ගොඩනගා ගත යුතුය.

5. සුචිගත කිරීම, පුරෝකථනය කිරීම සහ ප්‍රක්ෂේපණ

   අවම වශයෙන් 50% ක් මම කථා කරන අතර සමහර DBAs පවා දර්ශක ආවරණය කිරීමේ සංකල්පය සමඟ ගැටලු ඇති බව පෙනේ. ඔවුන් සිතන්නේ, "හොඳයි, Customer.Nameතීරුව සුචිගත කර ඇත, එබැවින් මම නම මත කරන සෑම විමසුමක්ම වේගවත් විය යුතුය." ඔබ සොයන නිශ්චිත තීරුව Nameදර්ශකය ආවරණය කරන්නේ නම් මිස එය එසේ ක්‍රියා නොකරයි . SQL සේවාදායකයේ, INCLUDEඑය CREATE INDEXප්‍රකාශයේ දක්වා ඇත.

   ඔබ SELECT *සෑම තැනකම අ ාන ලෙස භාවිතා කරන්නේ නම් - සහ ප්‍රක්ෂේපණයක් භාවිතා කිරීම ඔබ වෙනත් ආකාරයකින් නිශ්චිතව දක්වා නොමැති නම් එය සෑම ORM එකක්ම කරන්නේ අඩු හෝ වැඩි වශයෙන් නම් - එවිට DBMS ඔබේ දර්ශක ආවරණය නොකල තීරු අඩංගු බැවින් ඒවා සම්පූර්ණයෙන්ම නොසලකා හැරීමට තෝරා ගනු ඇත. ප්‍රක්ෂේපණයක් යනු මෙය සිදු කිරීම වෙනුවට, උදාහරණයක් ලෙස:

   from c in db.Customers where c.Name == "John Doe" select c
   

   ඔබ ඒ වෙනුවට මෙය කරන්නේ:

   from c in db.Customers where c.Name == "John Doe"
   select new { c.Id, c.Name }
   

   මෙම කැමැත්ත බොහෝ නූතන ORMs සඳහා, එය පමණක් යන්න හා විමසුම උපදෙස් ලබා Idහා Nameඅනුමාන දර්ශකය (නමුත් ආවරණය ලද තීරු Email, LastActivityDateහෝ වෙනත් ඕනෑම දෙයක් තීරු ඔබ එහි දී ඇලුම් කිරීමට සිදු).

   නුසුදුසු අනාවැකි භාවිතා කිරීමෙන් ඕනෑම සුචිගත කිරීමේ ප්‍රතිලාභ සම්පූර්ණයෙන්ම විනාශ කිරීම ද ඉතා පහසුය. උදාහරණයක් වශයෙන්:

   from c in db.Customers where c.Name.Contains("Doe")
   

   ... අපගේ පෙර විමසුමට බොහෝ දුරට සමාන බව පෙනේ, නමුත් ඇත්ත වශයෙන්ම එය සම්පූර්ණ වගුවක් හෝ දර්ශක පරිලෝකනයකට හේතු වනු ඇත LIKE '%Doe%'. ඒ හා සමානව, සැක සහිත ලෙස පෙනෙන තවත් විමසුමක් නම්:

   from c in db.Customers where (maxDate == null) || (c.BirthDate >= maxDate)
   

   ඔබට දර්ශකයක් තිබේ යැයි උපකල්පනය කරමින් BirthDate, මෙම අනාවැකිය එය සම්පූර්ණයෙන්ම නිෂ් .ල කිරීමට හොඳ අවස්ථාවක් තිබේ. මෙහි ඇති අපගේ උපකල්පිත ක්‍රමලේඛකයා පැහැදිලිවම යම් ආකාරයක ගතික විමසුමක් නිර්මාණය කිරීමට උත්සාහ කර ඇත ("එම පරාමිතිය නියම කර ඇත්නම් උපන්දිනය පමණක් පෙරහන් කරන්න"), නමුත් මෙය කිරීමට නිවැරදි ක්‍රමය මෙය නොවේ. ඒ වෙනුවට ලියා ඇත්තේ:

   from c in db.Customers where c.BirthDate >= (maxDate ?? DateTime.MinValue)
   

   ... දැන් ඩීබී එන්ජිම මෙය පරාමිතිකරණය කර දර්ශක සෙවීමක් කරන්නේ කෙසේදැයි දනී. විමසුම් ප්‍රකාශනයේ සුළු, සුළු වැදගත්කමක් ඇති වෙනසක් කාර්ය සාධනය කෙරෙහි දැඩි ලෙස බලපායි.

   අවාසනාවකට මෙන් LINQ සාමාන්‍යයෙන් මේ වගේ නරක විමසුම් ලිවීම පහසු කරයි, මන්ද සමහර විට සැපයුම්කරුවන්ට ඔබ කිරීමට උත්සාහ කළ දේ අනුමාන කිරීමට සහ විමසුම ප්‍රශස්ත කිරීමට හැකි වන අතර සමහර විට ඒවා එසේ නොවේ. Frustratingly සමග අවසන් නිසා ඔබ නොගැලපෙන ප්රතිඵල ඔබ සරල පැරණි SQL ලියා ඇති (කෙසේ හෝ, පළපුරුදු කරමින් තමයි කිරීමට) කරුණුය හැකිව තිබු.

   මූලික වශයෙන් ඒ සියල්ලට හේතුව ජනනය කරන ලද SQL සහ ඒවා මෙහෙයවන සැලසුම් පිළිබඳව ඔබ සැබවින්ම විමසිල්ලෙන් සිටිය යුතු අතර ඔබ අපේක්ෂා කරන ප්‍රති results ල නොලැබෙන්නේ නම්, මඟ හැරීමට බිය නොවන්න. ORM ස්තරය වරකට වරක් සහ SQL අතින් කේත කරන්න. මෙය EF පමණක් නොව ඕනෑම ORM සඳහා වේ.

6. ගනුදෙනු සහ අගුලු දැමීම

   මිලි තත්පර දක්වා පවතින දත්ත ප්‍රදර්ශනය කිරීමට ඔබට අවශ්‍යද? සමහර විට - එය රඳා පවතී - නමුත් බොහෝ විට එසේ නොවේ. නමුත් කනගාටුවට කරුණක්, ආයතනයක් රාමුව ඔබ දෙන්නේ නැහැnolock , ඔබ භාවිතා කළ හැක්කේ READ UNCOMMITTEDදී ගනුදෙනුව මට්ටම (නැහැ මේස මට්ටමේ). ඇත්ත වශයෙන්ම ORM කිසිවක් මේ පිළිබඳව විශේෂයෙන් විශ්වාසදායක නොවේ; ඔබට අපිරිසිදු කියවීම් කිරීමට අවශ්‍ය නම්, ඔබ SQL මට්ටමට බැස තාවකාලික විමසුම් හෝ ගබඩා කළ ක්‍රියා පටිපාටි ලිවිය යුතුය. එබැවින් එය නැවත නැවතත්, රාමුව තුළ එය කිරීම ඔබට කොතරම් පහසුද යන්න.

   ආයතන රාමුව මේ සම්බන්ධයෙන් බොහෝ දුරක් පැමිණ ඇත - EF හි 1 වන අනුවාදය (.NET 3.5 හි) දෙවියන් වහන්සේට භයානක වූ අතර, "ආයතන" වියුක්ත කිරීම බිඳ දැමීම ඇදහිය නොහැකි තරම් අපහසු විය, නමුත් දැන් ඔබට ExecuteStoreQuery සහ පරිවර්තනය ඇත , එබැවින් එය සැබවින්ම එතරම් නරක නැත. මෙම පුද්ගලයින් සමඟ මිත්‍රත්වයක් ඇති කරගන්න, මන්ද ඔබ ඔවුන් බොහෝ දේ භාවිතා කරනු ඇත.

   ලිවීමේ අගුලු දැමීම හා අවහිර කිරීම් පිළිබඳ ගැටළුව ද දත්ත ගබඩාවේ හැකි තරම් සුළු කාලයක් අගුල් තබා ගැනීමේ සාමාන්‍ය භාවිතාව ද ඇත. මේ සම්බන්ධයෙන් ගත් කල, බොහෝ ORMs (ආයතන රාමුව ඇතුළුව) ඇත්ත වශයෙන්ම අමු SQL වලට වඩා හොඳය. මන්දයත් ඒවා වැඩ රටාවේ ඒකකය වටකර ඇති හෙයිනි , එය EF හි SaveChanges වේ. වෙනත් වචන වලින් කිවහොත්, ඔබ වැඩ කරන ඒකකය සිදුකරන තුරු කිසිදු වෙනසක් සත්‍ය වශයෙන්ම දත්ත සමුදායට තල්ලු නොවන බවට දැනුමෙන් සුරක්ෂිතව, ඔබට අවශ්‍ය විටෙක, ඔබේ හදවතේ අන්තර්ගතයට "ඇතුළත් කිරීම" හෝ "යාවත්කාලීන කිරීම" හෝ "මකා දැමීම" කළ හැකිය.

   UOW දිගුකාලීන ගනුදෙනුවකට සමාන නොවන බව සලකන්න . UOW තවමත් ORM හි සුභවාදී සමගාමී ලක්ෂණ භාවිතා කරන අතර මතකයේ ඇති සියළු වෙනස්කම් නිරීක්ෂණය කරයි . අවසාන බැඳීම තෙක් එක් ඩීඑම්එල් ප්‍රකාශයක්වත් විමෝචනය නොවේ. මෙය ගනුදෙනු කාලය හැකි තරම් අඩු මට්ටමක තබා ගනී. අමු SQL භාවිතයෙන් ඔබ ඔබේ යෙදුම ගොඩනඟන්නේ නම්, මෙම විලම්බිත හැසිරීම සාක්ෂාත් කර ගැනීම තරමක් අපහසුය.

   විශේෂයෙන් EF සඳහා මෙයින් අදහස් කරන්නේ කුමක්ද: ඔබේ වැඩ ඒකක හැකි තරම් රළු බවට පත් කරන්න, ඔබට අවශ්‍ය වන තෙක් ඒවා නොකරන්න. මෙය කරන්න, ඔබ අහඹු වේලාවන්හි තනි ADO.NET විධානයන් භාවිතා කරනවාට වඩා අඩු අගුළු විවාදයකින් අවසන් වනු ඇත.

අවසන් තීරණයේ දී:

ඉහළ තදබදය / ඉහළ කාර්යසාධනය සහිත යෙදුම් සඳහා ඊඑෆ් සම්පූර්ණයෙන්ම හොඳයි, අනෙක් සෑම රාමුවක්ම ඉහළ තදබදය / ඉහළ කාර්යසාධනය සහිත යෙදුම් සඳහා හොඳයි. වැදගත් වන්නේ ඔබ එය භාවිතා කරන ආකාරයයි. මෙන්න වඩාත් ජනප්‍රිය රාමු සහ කාර්ය සාධනය අනුව ඔවුන් ඉදිරිපත් කරන අංග මොනවාද යන්න ඉක්මන් සංසන්දනයක් (පුරාවෘත්තය: එන් = සහාය නොදක්වයි, පී = අර්ධ, වයි = ඔව් / සහාය):

                                | L2S | EF1 | EF4 | NH3 | ADO
                                +-----+-----+-----+-----+-----
Lazy Loading (entities)         |  N  |  N  |  N  |  Y  |  N
Lazy Loading (relationships)    |  Y  |  Y  |  Y  |  Y  |  N
Eager Loading (global)          |  N  |  N  |  N  |  Y  |  N
Eager Loading (per-session)     |  Y  |  N  |  N  |  Y  |  N
Eager Loading (per-query)       |  N  |  Y  |  Y  |  Y  |  Y
Level 1 (Identity) Cache        |  Y  |  Y  |  Y  |  Y  |  N
Level 2 (Query) Cache           |  N  |  N  |  P  |  Y  |  N
Compiled Queries                |  Y  |  P  |  Y  |  N  | N/A
Multi-Queries                   |  N  |  N  |  N  |  Y  |  Y
Multiple Result Sets            |  Y  |  N  |  P  |  Y  |  Y
Futures                         |  N  |  N  |  N  |  Y  |  N
Explicit Locking (per-table)    |  N  |  N  |  N  |  P  |  Y
Transaction Isolation Level     |  Y  |  Y  |  Y  |  Y  |  Y
Ad-Hoc Queries                  |  Y  |  P  |  Y  |  Y  |  Y
Stored Procedures               |  Y  |  P  |  Y  |  Y  |  Y
Unit of Work                    |  Y  |  Y  |  Y  |  Y  |  N

ඔබට පෙනෙන පරිදි, EF4 (වර්තමාන අනුවාදය) එතරම් නරක නැත, නමුත් කාර්ය සාධනය ඔබේ මූලික සැලකිල්ල නම් එය හොඳම නොවේ. NHibernate මෙම ප්‍රදේශය තුළ වඩා පරිණත වන අතර SQL වෙත SQL පවා EF තවමත් නොකරන සමහර කාර්ය සාධනය වැඩි දියුණු කරන අංග සපයයි. අමු ADO.NET බොහෝ විට ඉතා නිශ්චිත දත්ත ප්‍රවේශ අවස්ථා සඳහා වේගවත් වනු ඇත, නමුත්, ඔබ සියලු කොටස් එකට දැමූ විට, එය සැබවින්ම විවිධ රාමු වලින් ඔබට ලැබෙන වැදගත් ප්‍රතිලාභ රාශියක් ලබා නොදේ.

තවද, මම බිඳුණු වාර්තාවක් ලෙස මුළුමනින්ම සහතික කර ගැනීම සඳහා , ඔබේ දත්ත සමුදාය, යෙදුම සහ දත්ත ප්‍රවේශ ක්‍රමෝපායන් නිසි ලෙස සැලසුම් නොකරන්නේ නම් මේ කිසිවක් සුළු වශයෙන් හෝ වැදගත් නොවේ. ඉහත වගුවේ ඇති සියලුම අයිතමයන් මූලික මට්ටමෙන් ඔබ්බට කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා ය ; බොහෝ විට, වඩාත්ම වැඩිදියුණු කිරීම අවශ්‍ය වන්නේ මූලිකම වේ.

සංස්කරණය කරන්න: aAaronaught විශිෂ්ට පිළිතුර මත පදනම්ව මම EF සමඟ කාර්ය සාධනය ඉලක්ක කර ගනිමින් කරුණු කිහිපයක් එකතු කරමි. එම නව කරුණු සංස්කරණය කරන්නේ උපසර්ගයෙනි.

ඉහළ ගමනාගමන වෙබ් අඩවි වල කාර්ය සාධනයේ විශාලතම දියුණුව ලබා ගත හැක්කේ හැඹිලිගත කිරීමෙනි (= පළමුවෙන්ම වෙබ් සේවාදායක සැකසුම් හෝ දත්ත සමුදා විමසීම් වලක්වා ගැනීම) ඉන්පසු දත්ත සමුදා විමසීම් සිදුකරන අතරතුර නූල් අවහිර වීම වළක්වා ගැනීම සඳහා අසමමුහුර්ත සැකසුම්.

ඔබගේ ප්‍රශ්නයට වෙඩි නොවදින පිළිතුරක් නොමැත, මන්ද එය සැමවිටම යෙදුම සඳහා වන අවශ්‍යතා සහ විමසුම් වල සංකීර්ණත්වය මත රඳා පවතී. සත්යය නම්, EF සමඟ සංවර්ධක produc ලදායිතාව සංකීර්ණත්වය සඟවන අතර එය බොහෝ විට වැරදි ලෙස EF භාවිතය හා භයානක ක්රියාකාරිත්වයට මග පාදයි. දත්ත ප්‍රවේශය සඳහා ඔබට ඉහළ මට්ටමේ වියුක්ත අතුරු මුහුණතක් නිරාවරණය කළ හැකි අතර එය සෑම අවස්ථාවකදීම සුමටව ක්‍රියා කරයි යන අදහස ක්‍රියාත්මක නොවේ. ORM සමඟ වුවද වියුක්ත කිරීම පිටුපස සිදුවන්නේ කුමක්ද සහ එය නිවැරදිව භාවිතා කරන්නේ කෙසේද යන්න ඔබ දැන සිටිය යුතුය.

ඔබට EF සමඟ පෙර අත්දැකීම් නොමැති නම්, කාර්ය සාධනය සමඟ කටයුතු කිරීමේදී ඔබට අභියෝග රැසකට මුහුණ දීමට සිදුවේ. ADO.NET හා සසඳන විට EF සමඟ වැඩ කිරීමේදී ඔබට තවත් බොහෝ වැරදි කළ හැකිය. එසේම EF හි අමතර සැකසුම් රාශියක් සිදු කර ඇත, එබැවින් EF සෑම විටම ස්වදේශික ADO.NET ට වඩා සැලකිය යුතු ලෙස මන්දගාමී වනු ඇත - එය සංකල්ප යෙදුම පිළිබඳ සරල සාක්ෂි මගින් ඔබට මැනිය හැකි දෙයකි.

ඔබට EF වෙතින් හොඳම කාර්ය සාධනය ලබා ගැනීමට අවශ්‍ය නම් ඔබට බොහෝ විට සිදු වනු ඇත්තේ:

• SQL පැතිකඩ සමඟ ඔබේ දත්ත ප්‍රවේශය ඉතා පරිස්සමින් සංශෝධනය කර ලින්ක් සිට වස්තු වෙනුවට ලින්ක්-ටු-එන්ටිටීස් නිවැරදිව භාවිතා කරන්නේ නම් ඔබේ ලින්ක් විමසුම් සමාලෝචනය කරන්න.
• වැනි උසස් EF ප්‍රශස්තිකරණ විශේෂාංග ඉතා ප්‍රවේශමෙන් භාවිතා කරන්න MergeOption.NoTracking
• සමහර අවස්ථාවල ESQL භාවිතා කරන්න
• බොහෝ විට ක්‍රියාත්මක වන විමසුම් පූර්ව සම්පාදනය කරන්න
• සමහර විමසුම් සඳහා "දෙවන මට්ටමේ හැඹිලිය" වැනි අංගයක් ලබා ගැනීම සඳහා ඊඑෆ් හැඹිලි එතීමෙන් ප්‍රයෝජන ගැනීම ගැන සිතන්න
• කාර්ය සාධනය වැඩි දියුණු කිරීම සඳහා බොහෝ විට භාවිතා කරන ප්‍රක්ෂේපණ හෝ එකතුව සඳහා SQL දර්ශන හෝ අභිරුචි සිතියම්ගත කළ SQL විමසුම් (EDMX ගොනුව අතින් නඩත්තු කිරීම අවශ්‍ය වේ) භාවිතා කරන්න.
• ලින්ක් හෝ ඊඑස්කියුඑල් හි අර්ථ දක්වා ඇති විට ප්‍රමාණවත් කාර්ය සාධනයක් ලබා නොදෙන සමහර විමසුම් සඳහා ස්වදේශීය SQL සහ ගබඩා කළ ක්‍රියා පටිපාටි භාවිතා කරන්න
• සංස්කරණය කරන්න: විමසීම් ප්‍රවේශමෙන් භාවිතා කරන්න - සෑම විමසුමක්ම දත්ත සමුදායට වෙන වෙනම වට රවුමක් සාදයි. ක්‍රියාත්මක කළ දත්ත සමුදා විධානයකට බහුවිධ ප්‍රති result ල කට්ටල භාවිතා කිරීමට නොහැකි නිසා EFv4 හට විමසුම් කාණ්ඩයක් නොමැත. සිතියම්ගත කළ ගබඩා කළ ක්‍රියා පටිපාටි සඳහා EFv4.5 බහු ප්‍රති result ල කට්ටල සඳහා සහාය වනු ඇත.
• සංස්කරණය කරන්න: දත්ත වෙනස් කිරීම් සමඟ ප්‍රවේශමෙන් වැඩ කරන්න. නැවතත් EF හි විධාන කාණ්ඩ කිරීම සම්පූර්ණයෙන්ම නොමැත . එබැවින් ADO.NET හි ඔබට SqlCommandබහු ඇතුළත් කිරීම්, යාවත්කාලීන කිරීම් හෝ මකාදැමීම් සහිත තනි භාවිතා කළ හැකි නමුත් EF සමඟ එවැනි සෑම විධානයක්ම වෙනම රවුන්ඩ් ට්‍රිප් එකකින් දත්ත සමුදායට ක්‍රියාත්මක වේ.
• සංස්කරණය කරන්න: අනන්‍යතා සිතියම / අනන්‍යතා හැඹිලිය සමඟ ප්‍රවේශමෙන් වැඩ කරන්න. හැඹිලිය මුලින් GetByKeyවිමසීමට EF ට විශේෂ ක්‍රමයක් ඇත ( ObjectContext API හෝ FindDbContext API හි). ඔබ ලින්ක්-ටු-එන්ටිටීස් හෝ ඊඑස්කියුඑල් භාවිතා කරන්නේ නම් එය දත්ත සමුදායට වටකුරු පටියක් සාදනු ඇති අතර ඉන් පසුව එය හැඹිලියෙන් පවතින අවස්ථාව නැවත ලබා දෙනු ඇත.
• සංස්කරණය කරන්න: උනන්දුවෙන් පැටවීම ප්‍රවේශමෙන් භාවිතා කරන්න . එය සෑම විටම ජයග්‍රාහී විසඳුමක් නොවේ, මන්ද එය එක් විශාල දත්ත කට්ටලයක් නිපදවන බැවිනි . ඔබට පෙනෙන පරිදි එය අතිරේක සංකීර්ණතාවයන් රාශියක් වන අතර එය සමස්ත කරුණයි. ORM සිතියම්කරණය සහ ද්‍රව්‍යකරණය සරල කරයි, නමුත් කාර්ය සාධනය සමඟ කටයුතු කිරීමේදී එය වඩාත් සංකීර්ණ වන අතර ඔබට වෙළඳාමෙන් ඉවත් වීමට සිදුවනු ඇත.

SO තවමත් L2S භාවිතා කරන්නේ දැයි මට විශ්වාස නැත. ඔවුන් ඩැපර් නමින් නව විවෘත මූලාශ්‍ර ORM සංවර්ධනය කළ අතර මෙම සංවර්ධනය පිටුපස ඇති ප්‍රධාන කරුණ කාර්ය සාධනය වැඩි කිරීමයි.