সংগ্রহস্থল প্যাটার্ন ব্যবহার না করে, ওআরএমটি (EF) হিসাবে ব্যবহার করুন


96

আমি সর্বদা রেপোজিটরি প্যাটার্ন ব্যবহার করি তবে আমার সর্বশেষ প্রকল্পের জন্য আমি এটি দেখতে এবং আমার "ইউনিট অব ওয়ার্ক" এর প্রয়োগটি নিখুঁত করতে পারি কিনা তা দেখতে চেয়েছিলাম। আমি যত বেশি খনন শুরু করেছি আমি নিজেকে প্রশ্ন জিজ্ঞাসা করতে শুরু করেছি: "আমার কি সত্যিই এটির প্রয়োজন?"

এখন এগুলি স্ট্যাকওভারফ্লোতে কয়েকটি মন্তব্য দিয়ে শুরু হয়েছিল যা তার ব্লগে আইয়েন্দে রাহিয়েনের পোস্টে 2 টি নির্দিষ্ট,

এটি সম্ভবত চিরকালের জন্য এবং সর্বদা সম্পর্কে কথা বলা যেতে পারে এবং এটি বিভিন্ন অ্যাপ্লিকেশনগুলির উপর নির্ভর করে। আমি যা জানতে পছন্দ করি,

  1. এই পদ্ধতির কোনও সত্তা ফ্রেমওয়ার্ক প্রকল্পের জন্য উপযুক্ত হবে?
  2. এই পদ্ধতির ব্যবহার করে কি ব্যবসায়ের যুক্তিগুলি কোনও পরিষেবা স্তরে বা এক্সটেনশন পদ্ধতিতে চলছে (নীচে বর্ণিত হিসাবে, আমি জানি, এক্সটেনশন পদ্ধতিটি এনএইচআইবি অধিবেশন ব্যবহার করছে)?

এটি সহজেই এক্সটেনশন পদ্ধতিগুলি ব্যবহার করে সম্পন্ন হয়েছে। পরিষ্কার, সহজ এবং পুনরায় ব্যবহারযোগ্য।

public static IEnumerable GetAll(
    this ISession instance, Expression<Func<T, bool>> where) where T : class
{
    return instance.QueryOver().Where(where).List();
}

এই পদ্ধতির ব্যবহার এবং Ninjectডিআই হিসাবে, আমার Contextইন্টারফেসগুলি তৈরি করতে এবং এটি আমার নিয়ামকদের মধ্যে ইনজেকশন করা দরকার?

উত্তর:


104

আমি অনেকগুলি পথ অবলম্বন করেছি এবং বিভিন্ন প্রকল্পে ভান্ডারগুলির অনেকগুলি বাস্তবায়ন তৈরি করেছি এবং ... আমি তোয়ালেটি ফেলে দিয়েছি এবং এটি দিয়ে দিয়েছি, কেন এখানে।

ব্যতিক্রম কোডিং

আপনার ডাটাবেসটি একটি প্রযুক্তি থেকে অন্য প্রযুক্তিতে পরিবর্তিত হতে চলেছে এমন 1% সুযোগের জন্য কি আপনি কোড করেন? যদি আপনি আপনার ব্যবসায়ের ভবিষ্যতের অবস্থা সম্পর্কে চিন্তাভাবনা করেন এবং হ্যাঁ এটির একটি সম্ভাবনা থাকে তবে ক) অন্য ডিবি প্রযুক্তিতে মাইগ্রেশন করার জন্য তাদের কাছে প্রচুর অর্থের পরিমাণ থাকতে হবে বা খ) আপনি মজাদার বা সি এর জন্য কোনও ডিবি প্রযুক্তি বেছে নিচ্ছেন ) আপনি যে প্রযুক্তি ব্যবহার করার সিদ্ধান্ত নিয়েছিলেন তাতে কোনও কিছু মারাত্মক ভুল হয়েছে wrong

সমৃদ্ধ লিনকিউ সিনট্যাক্সটি কেন ফেলে দিন?

লিনকুই এবং ইএফ বিকাশ করা হয়েছিল যাতে আপনি এটির সাথে ঝরঝরে স্টাফগুলি পড়তে এবং অবজেক্ট গ্রাফগুলি ট্র্যাভার্স করতে পারেন। একটি সংগ্রহস্থল তৈরি করা এবং রক্ষণাবেক্ষণ করা যা আপনাকে এটি করতে একই নমনীয়তা দিতে পারে এটি একটি রাক্ষসী কাজ। আমার অভিজ্ঞতার যে কোনও সময় আমি কোনও সংগ্রহশালা তৈরি করেছি আমার কাছে অনুসন্ধানগুলি আরও পারফরম্যান্ট করতে এবং / অথবা ডাটাবেসে হিট সংখ্যা হ্রাস করার জন্য সর্বদা রেজিস্ট্রি স্তরটিতে ব্যবসায়িক লজিক ফাঁস হয়েছিল।

আমি যে ক্যোয়ারিতে লিখতে হয় তার প্রতিটি একক ক্রমানুসারে একটি পদ্ধতি তৈরি করতে চাই না। আমি পাশাপাশি সঞ্চিত পদ্ধতি লিখতে পারি। আমি চাই না GetOrder, GetOrderWithOrderItem, GetOrderWithOrderItemWithOrderActivity, GetOrderByUserId, ইত্যাদি ... আমি শুধু প্রধান সত্তা এবং ঢুকা পেতে চান এবং বস্তুর গ্রাফ অন্তর্ভুক্ত আমি তাই দয়া করে।

সংগ্রহস্থলগুলির বেশিরভাগ উদাহরণ গুলশিত bull

আপনি যদি সত্যিই ব্লগের মতো কিছু খালি বা হাড়ের বিকাশ না করেন বা আপনার অনুসন্ধানগুলি रिपোরিটরি প্যাটার্নটির আশেপাশে ইন্টারনেটে আপনি যে উদাহরণ খুঁজে পেয়েছেন তার 90% এর মত কখনও সহজ হবে না। আমি এই যথেষ্ট চাপ দিতে পারি না! এটি এমন একটি জিনিস যা খুঁজে বের করার জন্য কাদামাটি দিয়ে ক্রল করতে হবে। সর্বদা এমন একটি ক্যোয়ারী থাকবে যা আপনার তৈরি করা আপনার সঠিক চিন্তাভাবনা ভাণ্ডার / সমাধানটি ভেঙে দেয় এবং আপনি নিজের অনুমান এবং প্রযুক্তিগত debtণ / ক্ষয় শুরু না হওয়া অবধি এটি নয়।

আমার ইউনিট পরীক্ষা না

তবে ইউনিট টেস্টিংয়ের বিষয়ে যদি আমার কাছে কোনও সংগ্রহস্থল না থাকে? কীভাবে উপহাস করব? সরল, আপনি না। উভয় কোণ থেকে এটি তাকান:

কোনও সংগ্রহস্থল নয় - আপনি DbContextকোনও IDbContextবা অন্য কিছু কৌশল ব্যবহার করে উপহাস করতে পারেন তবে তারপরে আপনি অবজেক্টগুলিতে লিনকিউ পরীক্ষা করছেন এবং লিনকু থেকে সত্তা নয়, কারণ ক্যোয়ারী রানটাইম সময়ে নির্ধারিত হয়েছে ... ঠিক আছে তাই ভাল না! সুতরাং এখন এটি কভার ইন্টিগ্রেশন পরীক্ষা আপ।

সংগ্রহস্থল সহ - আপনি এখন আপনার সংগ্রহস্থলগুলিকে উপহাস করতে পারেন এবং মাঝখানে স্তর (গুলি) এর ইউনিট পরীক্ষা করতে পারেন। দুর্দান্ত? সত্যিই ঠিক নেই ... উপরের ক্ষেত্রে যেখানে প্রশ্নগুলিকে আরও পারফরম্যান্ট করতে এবং / অথবা ডাটাবেসে কম হিট করতে আপনার ভাণ্ডার স্তরটিতে যুক্তি ফাঁস করতে হবে, আপনার ইউনিট পরীক্ষাগুলি কীভাবে এটি কভার করতে পারে? এটি এখন রেপো স্তরে রয়েছে এবং আপনি এখনই পরীক্ষা করতে চান না IQueryable<T>? এছাড়াও আসুন সত্য কথা বলা যাক, আপনার ইউনিট পরীক্ষাগুলি 20 লাইনের একটি .Where()ধারা রয়েছে এমন কোয়েরিগুলি কভার করে না.Include()সম্পর্কের একটি গোছা এবং এই সমস্ত অন্যান্য জিনিসগুলি করতে আবার ডেটাবেসকে হিট করে, ব্লা, ব্লা, ব্লাহ যাইহোক, কারণ ক্যোয়ারী রানটাইমের সময় উত্পন্ন হয়েছিল। আপনি যেহেতু উপরের স্তরগুলিকে অজানা রাখার জন্য একটি সংগ্রহশালা তৈরি করেছেন, আপনি যদি এখন আপনার ডাটাবেস প্রযুক্তি পরিবর্তন করতে চান তবে দুঃখিত, আপনার ইউনিট পরীক্ষাগুলি অবশ্যই রানটাইমের সময় একই ফলাফলের গ্যারান্টি দিতে যাচ্ছে না, ইন্টিগ্রেশন পরীক্ষায় ফিরে। সুতরাং সংগ্রহস্থলের পুরো পয়েন্টটি অদ্ভুত বলে মনে হচ্ছে ..

2 সেন্ট

প্লেইন স্টোরেজ পদ্ধতি (বাল্ক সন্নিবেশ, বাল্ক মোছা, সিটিই, ইত্যাদি) এর উপর EF ব্যবহার করার সময় আমরা ইতিমধ্যে প্রচুর কার্যকারিতা এবং বাক্য গঠন হারিয়ে ফেলেছি তবে আমি সি # তেও কোড করি যাতে আমাকে বাইনারি টাইপ করতে হয় না। আমরা ইএফ ব্যবহার করি যাতে আমাদের বিভিন্ন সরবরাহকারী ব্যবহার করার এবং বিভিন্ন জিনিসের মধ্যে সুন্দর সম্পর্কিত উপায়ে অবজেক্ট গ্রাফগুলির সাথে কাজ করার সম্ভাবনা থাকতে পারে। কিছু বিমূর্ততা দরকারী এবং কিছু না।


18
সেগুলির একক পরীক্ষায় সক্ষম হতে আপনি সংগ্রহস্থলগুলি তৈরি করেন না। আপনি ব্যবসার যুক্তি পরীক্ষা করতে সক্ষম হতে সঞ্চয়ী তৈরি করেন । অনুসন্ধানগুলি যে কাজ করে তা নিশ্চিত করার জন্য: সংগ্রহশালাগুলির জন্য ইন্টিগ্রেশন পরীক্ষাগুলি লেখা অনেক সহজ কারণ এগুলিতে কেবল যুক্তি রয়েছে এবং কোনও ব্যবসা নেই।
jgauffin

16
Coding for the exception: সংগ্রহশালা ব্যবহার করে ডাটাবেস ইঞ্জিন স্যুইচ করতে সক্ষম হবেনা। এটি অধ্যবসায় থেকে ব্যবসায়কে আলাদা করার বিষয়ে।
jgauffin

4
এগুলি তাদের পিছনে একটি দুর্দান্ত চুক্তি সহ খুব কার্যকর পয়েন্ট। তবে যেটির অভাব রয়েছে তার উপলব্ধি হ'ল একটি লম্বা স্থানে সীমাবদ্ধ না রেখে লিনকিউ একটি অ্যাপ্লিকেশন সম্পর্কে প্রসারিত কোডবেইন্ড পৃষ্ঠাগুলিতে এসকিউএল কলগুলির সমতুল্য EF তৈরি করে। প্রতিটি লিনিক্যু ক্যোয়ারী একটি অ্যাপ্লিকেশনটির একটি সম্ভাব্য রক্ষণাবেক্ষণ পয়েন্ট এবং সেখানে যত বেশি থাকে (এবং সেগুলি আরও বিস্তৃত হয়), রক্ষণাবেক্ষণ ব্যয় এবং ঝুঁকি তত বেশি। কোনও সত্তায় একটি 'মোছা' পতাকা যুক্ত করার এবং একককে একটি বৃহত অ্যাপ্লিকেশনটিতে সন্ধান করার জন্য প্রত্যেকটি জায়গা আবিষ্কার করার কল্পনা করুন, প্রতিটি সংশোধন করার জন্য ...
ডিভি কে

4
আমি মনে করি এটি স্বল্পদৃষ্টির এবং জেড। আপনি কেন রেপোতে লজিক ফাঁস করবেন? আপনি যদি তা করেন তবে তা কেন ব্যাপার? এটি একটি ডেটা বাস্তবায়ন। আমরা যা করছি তা লিনকোটিকে রেপোর পিছনে লুকিয়ে রেখে বাকী কোড থেকে বন্ধ করে দিচ্ছে। আপনি বলছেন এটি পরীক্ষা করবেন না, তবে তারপরে আপনি এটির বিরুদ্ধে যুক্তি হিসাবে এটি পরীক্ষা করতে সক্ষম হবেন না। সুতরাং রেপো তৈরি করুন, আইকোয়ারিযোগ্যকে প্রকাশ করবেন না এবং এটি পরীক্ষাও করবেন না। ডেটা বাস্তবায়ন থেকে কমপক্ষে আপনি বিচ্ছিন্নভাবে অন্য সমস্ত কিছুর পরীক্ষা করতে পারেন। এবং একটি ডিবি পরিবর্তনের 1% সম্ভাবনা এখনও-এক বিশাল।
সিনেটেস্ট্যাটিক

4
এই উত্তরের জন্য +1। আমি দেখতে পেয়েছি যে সত্যই আমাদের সত্তা ফ্রেমওয়ার্ক কোর সহ সংগ্রহস্থলের প্রয়োজন নেই। এটি DbSetহ'ল ভাণ্ডার , এবং DbContextএটি কাজের একক । ওআরএম যখন ইতিমধ্যে আমাদের জন্য এটি করে তখন কেন সংগ্রহস্থল প্যাটার্ন বাস্তবায়ন করা হয়! পরীক্ষার জন্য, কেবল সরবরাহকারীতে পরিবর্তন করুন InMemory। এবং আপনার পরীক্ষা করুন! এটি এমএসডিএন-তে ভাল নথিভুক্ত।
মোহাম্মদ নুরাল্ডিন

49

সংগ্রহস্থল প্যাটার্নটি একটি বিমূর্ততা । এর উদ্দেশ্যটি হ'ল জটিলতা হ্রাস করা এবং বাকী কোডটিকে অবিচ্ছিন্ন করা। বোনাস হিসাবে এটি আপনাকে ইন্টিগ্রেশন পরীক্ষার পরিবর্তে ইউনিট পরীক্ষা লেখার অনুমতি দেয় ।

সমস্যাটি হ'ল অনেক বিকাশকারী নিদর্শনগুলির উদ্দেশ্য বুঝতে এবং সংগ্রহস্থল তৈরি করতে ব্যর্থ হন যা কলারের কাছে স্থিরতা সম্পর্কিত নির্দিষ্ট তথ্য ফাঁস করে (সাধারণত প্রকাশ করে IQueryable<T>)। এটি করে তারা সরাসরি ওআর / এম ব্যবহার করে কোনও সুবিধা পান না।

অন্য উত্তর ঠিকানা ঠিকানা আপডেট করুন

ব্যতিক্রম কোডিং

সংগ্রহস্থলগুলি ব্যবহার করা অধ্যবসায় প্রযুক্তি পরিবর্তন করতে সক্ষম হবার নয় (যেমন ডাটাবেস পরিবর্তন করা বা পরিবর্তে ওয়েবসার্ভিস ব্যবহার ইত্যাদি)। এটি জটিলতা এবং সংযোগ কমাতে অধ্যবসায় থেকে ব্যবসায় যুক্তি যুক্ত করার বিষয়ে।

ইউনিট পরীক্ষা বনাম ইন্টিগ্রেশন পরীক্ষা

আপনি সংগ্রহস্থলের জন্য ইউনিট পরীক্ষা লিখবেন না। পিরিয়ড

কিন্তু সংগ্রহস্থলগুলি (বা স্থিরতা এবং ব্যবসায়ের মধ্যে অন্য কোনও বিমূর্ত স্তর) প্রবর্তন করে আপনি ব্যবসায়ের যুক্তির জন্য ইউনিট পরীক্ষা লিখতে সক্ষম হন। অর্থাত্ ভুলভাবে কনফিগার করা ডাটাবেসের কারণে আপনার পরীক্ষাগুলি ব্যর্থ হওয়ার বিষয়ে আপনাকে উদ্বিগ্ন হওয়ার দরকার নেই।

প্রশ্ন হিসাবে। আপনি যদি লিনকিউ ব্যবহার করেন তবে আপনার অনুসন্ধানগুলি ঠিক যেমন আপনার সংগ্রহস্থলগুলির সাথে করা উচিত তাও নিশ্চিত করতে হবে। এবং এটি ইন্টিগ্রেশন টেস্ট ব্যবহার করে করা হয়।

পার্থক্যটি হ'ল যদি আপনি লিনকিউ বিবৃতিগুলির সাথে আপনার ব্যবসায়কে মিশ্রিত না করেন তবে আপনি 100% নিশ্চিত হতে পারেন যে এটি আপনার দৃistence়তার কোড যা ব্যর্থ হচ্ছে এবং অন্য কিছু নয়।

আপনি যদি নিজের পরীক্ষাগুলি বিশ্লেষণ করেন তবে আপনি দেখতে পাবেন যে আপনার যদি মিশ্র উদ্বেগ না থাকে তবে (যেমন লিনকিউ + ব্যবসায়িক যুক্তি)

ভান্ডার উদাহরণ

বেশিরভাগ উদাহরণ গুলশিত are এটা আসলেই সত্য. তবে, আপনি যদি কোনও ডিজাইনের প্যাটার্ন গুগল করেন তবে আপনি অনেকগুলি কৃপণ উদাহরণ পাবেন। কোনও প্যাটার্ন ব্যবহার এড়াতে কোনও কারণ নেই।

একটি সঠিক সংগ্রহস্থল বাস্তবায়ন তৈরি করা খুব সহজ। আসলে, আপনাকে কেবল একটি নিয়ম অনুসরণ করতে হবে:

আপনার প্রয়োজন হওয়া মুহুর্ত পর্যন্ত সংগ্রহশালা শ্রেণিতে কোনও কিছু যুক্ত করবেন না

পরিকল্পনাটি অনেক অলস এবং চেষ্টা একটি জেনেরিক সংগ্রহস্থলের করতে হয় এবং পদ্ধতি যে, তারা অনেক সঙ্গে একটি বেস বর্গ ব্যবহার পারে প্রয়োজন। ইয়াগনি আপনি একবার সংগ্রহস্থল শ্রেণি লিখবেন এবং যতক্ষণ অ্যাপ্লিকেশন বেঁচে থাকবে ততক্ষণ রাখবে (বছর হতে পারে)। অলস হয়ে কেন এটাকে চুদব। কোনও বেস শ্রেণীর উত্তরাধিকার ছাড়াই এটি পরিষ্কার রাখুন। এটি পড়া এবং বজায় রাখা আরও সহজ করে তুলবে।

(উপরের বিবৃতিটি কোনও আইন নয়, একটি গাইডলাইন। একটি বেস শ্রেণিটি খুব ভালভাবে অনুপ্রাণিত হতে পারে it এটি যুক্ত করার আগে কেবল ভাবুন, যাতে আপনি এটি সঠিক কারণে যুক্ত করেন)

পুরোনো কাপড়

উপসংহার:

আপনি যদি আপনার ব্যবসায়ের কোডে লিনকিউ বিবৃতি না রাখেন বা ইউনিট পরীক্ষাগুলির যত্ন না রাখেন তবে আমি সরাসরি সত্ত্বা ফ্রেমওয়ার্কটি ব্যবহার না করার কোনও কারণ দেখতে পাচ্ছি না।

হালনাগাদ

আমি সংগ্রহস্থল প্যাটার্ন এবং "বিমূর্ততা" এর অর্থ কী তা সম্পর্কে উভয়ই ব্লগ করেছি: http://blog.gauffin.org/2013/01/repository-pattern-done-right/

আপডেট 2

20+ ক্ষেত্র সহ একক সত্তা প্রকারের জন্য, আপনি কোনও অনুমানের সংমিশ্রণ সমর্থন করার জন্য কোয়েরি পদ্ধতিটি কীভাবে ডিজাইন করবেন? আপনি কেবল নাম দ্বারা অনুসন্ধান সীমাবদ্ধ করতে চান না, নেভিগেশন বৈশিষ্ট্যগুলির সাথে অনুসন্ধান সম্পর্কে কী, নির্দিষ্ট মূল্য কোড সহ আইটেমের সাথে সমস্ত অর্ডার তালিকাভুক্ত করুন, নেভিগেশন সম্পত্তি অনুসন্ধানের 3 স্তর। পুরো কারণটি IQueryableআবিষ্কার করা হয়েছিল এটি ডাটাবেসের বিরুদ্ধে অনুসন্ধানের যে কোনও সংমিশ্রণ রচনা করতে সক্ষম হয়েছিল। তত্ত্বটিতে সবকিছু দুর্দান্ত দেখায় তবে ব্যবহারকারীর প্রয়োজন তত্ত্বের উপরে জয়ী হয়।

আবার: 20+ ক্ষেত্র সহ একটি সত্তা ভুলভাবে মডেলিং। এটি একটি entityশ্বরের সত্তা। এটি ভেংগে ফেল.

আমি তর্ক করছি না যে IQueryableজিজ্ঞাসা জন্য তৈরি করা হয়নি। আমি বলছি যে এটি সংগ্রহস্থল প্যাটার্নের মতো বিমূর্ত স্তরটির জন্য এটি সঠিক নয় কারণ এটি ফুটো হয়ে যায়। এসকিএল সরবরাহকারীর (ইএফ এর মতো) কোনও 100% সম্পূর্ণ লিনিকিউ নেই।

তাদের সকলের কীভাবে উত্সাহী / অলস লোডিং ব্যবহার করা যায় বা এসকিউএল "IN" বিবৃতিগুলি কীভাবে করা যায় সে সম্পর্কিত নির্দিষ্টকরণ রয়েছে। IQueryableসংগ্রহস্থলে প্রকাশের ফলে ব্যবহারকারীকে সেই সমস্ত জিনিস জানতে বাধ্য করা হয়। সুতরাং ডেটা উত্স দূরে বিমূর্ত করার সম্পূর্ণ প্রচেষ্টা একটি সম্পূর্ণ ব্যর্থতা। আপনি সরাসরি ওআর / এম ব্যবহার করে কোনও সুবিধা না পেয়ে কেবল জটিলতা যুক্ত করেন।

হয় সংগ্রহস্থল প্যাটার্নটি সঠিকভাবে প্রয়োগ করুন বা এটি একেবারেই ব্যবহার করবেন না।

(আপনি যদি সত্যিই বড় সত্ত্বাগুলি পরিচালনা করতে চান তবে আপনি স্পেসিফিকেশন প্যাটার্নের সাথে সংগ্রহস্থল প্যাটার্নটি একত্রিত করতে পারেন That এটি আপনাকে একটি সম্পূর্ণ বিমূর্ততা দেয় যা পরীক্ষাযোগ্য is


6
আইকিউয়েরেবল সীমিত সন্ধানের দিকে না ফেলে, লোকেরা বিভিন্ন ধরণের প্রশ্নের জন্য আরও পদ্ধতি অর্জন করে এবং শেষ পর্যন্ত এটি সংগ্রহশালাকে আরও জটিল করে তোলে।
আকাশ কাভা

4
আপনি মূল বিষয়টিকে মোটেই সম্বোধন করেননি: একটি সংগ্রহস্থলের মাধ্যমে আইকিউয়েরেবল এক্সপোজ করা সম্পূর্ণ বিমূর্ততা নয়।
jgauffin

4
একটি ক্যোয়ারী অবজেক্ট থাকা যার মধ্যে সম্পাদিত হওয়ার জন্য প্রয়োজনীয় সমস্ত অবকাঠামো রয়েছে এবং এটি ইমো যাওয়ার উপায়। আপনি এটিকে ক্ষেত্রগুলি যা অনুসন্ধান পদ এবং এটি ফলাফলের একটি তালিকা প্রদান করে। কিউওর অভ্যন্তরীণ আপনি যা খুশি করতে পারেন। এবং এটি একটি ইন্টারফেস, তাই সহজেই পরীক্ষা করা হয়। উপরে আমার পোস্ট দেখুন। এটা ভাল.
এইচ.এলেক্স

4
ব্যক্তিগতভাবে, আমি মনে করি এটির কোনও সদস্যের অন্তর্নিহিত সেটটি প্রকাশ করার পরিবর্তে কোনও সংগ্রহস্থল ক্লাসে আইকিউয়েরেবল <T> ইন্টারফেস বাস্তবায়ন করাও বোধগম্য।
অন্ধকার_পারফেক্ট

4
@ আয়: সমষ্টিগত মূলের জন্য একটি প্রতিস্থাপন। তবে ইমো এটি টেবিলগুলির সামগ্রিক মূল এবং সমষ্টি নয়, কেবলমাত্র সমষ্টিগত মূল এবং সমষ্টি । প্রকৃত স্টোরেজটিতে কেবলমাত্র একটি টেবিল বা এগুলি প্রচুর ব্যবহার করা যেতে পারে, অর্থাত্ এটি প্রতিটি সমষ্টি এবং একটি টেবিলের মধ্যে এক-একের ম্যাপিং নাও হতে পারে। জটিলতা হ্রাস করতে এবং অন্তর্নিহিত স্টোরেজের কোনও নির্ভরতা অপসারণ করতে আমি সংগ্রহস্থলগুলি ব্যবহার করি।
jgauffin

29

আইএমও Repositoryবিমূর্ততা এবং বিমূর্ততা উভয় UnitOfWorkঅর্থপূর্ণ বিকাশে একটি খুব মূল্যবান স্থান আছে have লোকেরা বাস্তবায়নের বিশদ সম্পর্কে তর্ক করবে, তবে যেমন একটি বিড়ালকে ত্বকে নেওয়ার বিভিন্ন উপায় রয়েছে, তেমনি বিমূর্তি বাস্তবায়নেরও অনেক উপায় রয়েছে।

আপনার প্রশ্নটি বিশেষভাবে ব্যবহার করার জন্য বা ব্যবহার না করার জন্য এবং কেন।

আপনি কোন সন্দেহ বুঝতে পেরেছি হিসাবে আপনি ইতিমধ্যে উভয় এই নিদর্শন সত্তা ফ্রেমওয়ার্ক পাতাটা আছে DbContextহয় UnitOfWorkএবং DbSetহয় Repository। আপনি সাধারণত ইউনিট পরীক্ষা করার প্রয়োজন হবে না UnitOfWorkবা Repositoryতারা কেবল আপনার ক্লাস এবং অন্তর্নিহিত ডেটা অ্যাক্সেস বাস্তবায়নের মধ্যে সুবিধা হয় নিজেদের। আপনার পরিষেবাগুলির যুক্তি পরীক্ষা করার সময় আপনি যখন নিজেকে বার বার প্রয়োজন হবে তা হ'ল এই দুটি বিমূর্ততাটিকে উপহাস করে।

আপনি লক এবং পরীক্ষার জন্য যুক্তিটির মধ্যে কোড নির্ভরতাগুলির স্তরগুলি (যা আপনি নিয়ন্ত্রণ করেন না) যুক্ত করে বহিরাগত লাইব্রেরিগুলির সাথে আপনি উপহাস, জাল বা যা কিছু করতে পারেন

সুতরাং একটি ছোটখাটো বিষয় হ'ল আপনার ইউনিট পরীক্ষাগুলি উপহাস করার সময় আপনার নিজস্ব বিমূর্ততা থাকা UnitOfWorkএবং Repositoryআপনাকে সর্বাধিক নিয়ন্ত্রণ এবং নমনীয়তা দেয়।

সব কিছু খুব ভাল, তবে আমার কাছে, এই বিমূর্ততার আসল শক্তি হ'ল এএসপেক্ট ওরিয়েন্টেড প্রোগ্রামিং কৌশলগুলি প্রয়োগ করার এবং সলিড নীতিগুলি মেনে চলার একটি সহজ উপায় ।

সুতরাং আপনি আপনার IRepository:

public interface IRepository<T>
    where T : class
{
    T Add(T entity);
    void Delete(T entity);
    IQueryable<T> AsQueryable();
}

এবং এর বাস্তবায়ন:

public class Repository<T> : IRepository<T>
    where T : class
{
    private readonly IDbSet<T> _dbSet;
    public Repository(PPContext context) 
    {
        _dbSet = context.Set<T>();
    }

    public T Add(T entity)
    { 
        return _dbSet.Add(entity); 
    }

    public void Delete(T entity)
    {
        _dbSet.Remove(entity); 
    }

    public IQueryable<T> AsQueryable() 
    {
        return _dbSet.AsQueryable();
    }
}

সাধারণের বাইরে এখন পর্যন্ত কিছুই নেই তবে এখন আমরা কিছু লগিং যুক্ত করতে চাই - লগিং ডেকরেটারের সাহায্যে সহজ ।

public class RepositoryLoggerDecorator<T> : IRepository<T>
    where T : class
{
    Logger logger = LogManager.GetCurrentClassLogger();
    private readonly IRepository<T> _decorated;
    public RepositoryLoggerDecorator(IRepository<T> decorated)
    {
        _decorated = decorated;
    }

    public T Add(T entity)
    {
        logger.Log(LogLevel.Debug, () => DateTime.Now.ToLongTimeString() );
        T added = _decorated.Add(entity);
        logger.Log(LogLevel.Debug, () => DateTime.Now.ToLongTimeString());
        return added;
    }

    public void Delete(T entity)
    {
        logger.Log(LogLevel.Debug, () => DateTime.Now.ToLongTimeString());
        _decorated.Delete(entity);
        logger.Log(LogLevel.Debug, () => DateTime.Now.ToLongTimeString());
    }

    public IQueryable<T> AsQueryable()
    {
        return _decorated.AsQueryable();
    }
}

সবই করা হয়েছে এবং আমাদের বিদ্যমান কোডটিতে কোনও পরিবর্তন নেই । আমরা যুক্ত করতে পারি এমন আরও অনেক ক্রস উদ্বেগ রয়েছে যেমন ব্যতিক্রম হ্যান্ডলিং, ডেটা ক্যাশিং, ডেটা যাচাইকরণ বা যা কিছু এবং আমাদের ডিজাইন এবং বিল্ড প্রসেসের মধ্যে আমাদের কাছে সবচেয়ে মূল্যবান জিনিস যা আমাদের বিদ্যমান কোডের কোনও পরিবর্তন না করেই সাধারণ বৈশিষ্ট্যগুলি যুক্ত করতে সক্ষম করে আমাদের IRepositoryবিমূর্ততা

এখন, স্ট্যাকওভারফ্লোতে আমি এই প্রশ্নটি অনেকবার দেখেছি - "আপনি কীভাবে বহু ভাড়াটে পরিবেশে এন্টি ফ্রেমওয়ার্ককে কাজ করবেন?"

https://stackoverflow.com/search?q=%5 Bentity-framework%5D+ মাল্টি +++

আপনার যদি কোনও Repositoryবিমূর্ততা থাকে তবে উত্তরটি হ'ল "এটি সহজেই একটি সাজসজ্জা যুক্ত করুন"

public class RepositoryTennantFilterDecorator<T> : IRepository<T>
    where T : class
{
    //public for Unit Test example
    public readonly IRepository<T> _decorated;
    public RepositoryTennantFilterDecorator(IRepository<T> decorated)
    {
        _decorated = decorated;
    }

    public T Add(T entity)
    {
        return _decorated.Add(entity);
    }

    public void Delete(T entity)
    {
        _decorated.Delete(entity);
    }

    public IQueryable<T> AsQueryable()
    {
        return _decorated.AsQueryable().Where(o => true);
    }
}

আইএমও আপনার সর্বদা কোনও তৃতীয় পক্ষের উপাদানগুলির উপরে একটি সরল বিমূর্ততা স্থাপন করা উচিত যা মুষ্টিমেয় জায়গাগুলির চেয়েও বেশি জায়গায় রেফারেন্স করা হবে। এই দৃষ্টিকোণ থেকে একটি ORM হ'ল নিখুঁত প্রার্থী হিসাবে এটি আমাদের কোডের অনেকগুলিতে উল্লেখ করা হয়।

উত্তরটি সাধারণত মনে আসে যখন কেউ বলে যে "কেন Repositoryএই বা তৃতীয় পক্ষের লাইব্রেরিটির উপরে আমার বিমূর্ততা (উদাহরণস্বরূপ ) হওয়া উচিত " "আপনি কেন করবেন না?"

পিএস ডেকোরেটরগুলি আইওসি পাত্রে যেমন সিম্পল ইনজেক্টর ব্যবহার করে আবেদন করা অত্যন্ত সহজ ।

[TestFixture]
public class IRepositoryTesting
{
    [Test]
    public void IRepository_ContainerRegisteredWithTwoDecorators_ReturnsDecoratedRepository()
    {
        Container container = new Container();
        container.RegisterLifetimeScope<PPContext>();
        container.RegisterOpenGeneric(
            typeof(IRepository<>), 
            typeof(Repository<>));
        container.RegisterDecorator(
            typeof(IRepository<>), 
            typeof(RepositoryLoggerDecorator<>));
        container.RegisterDecorator(
            typeof(IRepository<>), 
            typeof(RepositoryTennantFilterDecorator<>));
        container.Verify();

        using (container.BeginLifetimeScope())
        {
            var result = container.GetInstance<IRepository<Image>>();

            Assert.That(
                result, 
                Is.InstanceOf(typeof(RepositoryTennantFilterDecorator<Image>)));
            Assert.That(
                (result as RepositoryTennantFilterDecorator<Image>)._decorated,
                Is.InstanceOf(typeof(RepositoryLoggerDecorator<Image>)));
        }
    }
}

মজার বিষয় হল, এই উত্তরটি এখনও ২০২০ সালে প্রাসঙ্গিক। আরপি প্রতিস্থাপনের জন্য খুব বেশি পদ্ধতি নেই
ভলকান জিভেন

11

প্রথমত, কিছু উত্তরের পরামর্শ অনুসারে, ইএফ নিজেই একটি সংগ্রহশালার প্যাটার্ন, এটি কেবল সংগ্রহস্থল হিসাবে নামকরণ করার জন্য আরও বিমূর্ততা তৈরি করার প্রয়োজন নেই।

ইউনিট টেস্টের জন্য মকেটেবল সংগ্রহশালা, আমাদের কি সত্যিই এটির প্রয়োজন?

আমরা এসএকিউএল টেস্ট ডিবির বিরুদ্ধে সরাসরি আমাদের ব্যবসায়িক যুক্তি পরীক্ষা করতে ইউনিট পরীক্ষায় ডিবি পরীক্ষার জন্য EF কে যোগাযোগ করতে দেব communicate কোনও রেপোজিটরি প্যাটার্নের উপহাস করার কোনও সুবিধা আমি দেখতে পাচ্ছি না। পরীক্ষার ডাটাবেসের বিরুদ্ধে ইউনিট পরীক্ষা করা আসলে কী ভুল? যেহেতু এটি প্রচুর অপারেশন সম্ভব নয় এবং আমরা কাঁচা এসকিউএল লেখা শেষ করি। মেমরির এসকিউএলাইট বাস্তব ডাটাবেসের বিরুদ্ধে ইউনিট পরীক্ষা করার জন্য নিখুঁত প্রার্থী।

অপ্রয়োজনীয় বিমূর্ততা

ভবিষ্যতে আপনি সহজেই এনএফবিবার্নেট ইত্যাদি বা অন্য কোনও কিছুর সাথে EF প্রতিস্থাপন করতে পারেন তাই আপনি কি ভান্ডার তৈরি করতে চান? দুর্দান্ত পরিকল্পনা মনে হচ্ছে, তবে এটি কি সত্যিই কার্যকর?

লিনক ইউনিট পরীক্ষা মেরে ফেলেছে?

এটি কীভাবে হত্যা করতে পারে তার কোনও উদাহরণ আমি দেখতে চাই।

নির্ভরতা ইনজেকশন, আইওসি

বাহ এগুলি দুর্দান্ত শব্দ, অবশ্যই তারা তাত্ত্বিকভাবে দুর্দান্ত দেখায় তবে কখনও কখনও আপনাকে দুর্দান্ত নকশা এবং দুর্দান্ত সমাধানের মধ্যে বাণিজ্য বেছে নিতে হয়। আমরা সেগুলি সবই ব্যবহার করেছিলাম এবং আমরা সবগুলি ট্র্যাশে ফেলে দিয়েছি এবং আলাদা পদ্ধতি বেছে নিয়েছি। সাইজ বনাম গতি (কোডের আকার এবং বিকাশের গতি) বাস্তব জীবনে বিশাল বিষয়। ব্যবহারকারীদের নমনীয়তা প্রয়োজন, তারা ডিআই বা আইওসি-র ক্ষেত্রে আপনার কোড ডিজাইনে দুর্দান্ত কিনা তা বিবেচ্য নয়।

যদি না আপনি ভিজ্যুয়াল স্টুডিও নির্মাণ করছেন

আপনি যদি ভিজ্যুয়াল স্টুডিও বা Eclipse এর মতো একটি জটিল প্রোগ্রাম তৈরি করছেন যা অনেক লোক বিকাশ করবে এবং এটিকে অত্যন্ত স্বনির্ধারিত করা দরকার যদি এই সমস্ত দুর্দান্ত নকশার প্রয়োজন হয়। এই আইডিইগুলি বছরের পর বছর বিকাশের পরে সমস্ত দুর্দান্ত বিকাশের চিত্র চিত্রায় এসেছে এবং তারা এমন জায়গায় বিকশিত হয়েছে যেখানে এই দুর্দান্ত ডিজাইনের ধরণগুলি এতটাই গুরুত্বপূর্ণ। তবে যদি আপনি সাধারণ ওয়েব ভিত্তিক বেতনভিত্তিক, বা সাধারণ ব্যবসায়িক অ্যাপ্লিকেশনটি করেন তবে এটি মিলিয়ন ব্যবহারকারীদের জন্য এটির জন্য সময় ব্যয় করার পরিবর্তে সময়ের সাথে আপনার বিকাশে উন্নত হওয়া ভাল যেখানে এটি কেবলমাত্র 100s ব্যবহারকারীর জন্য মোতায়েন করা হবে।

ফিল্টার করা ভিউ - আইসিকিউররেপোজিটরি হিসাবে সংগ্রহস্থল

অন্যদিকে, সংগ্রহস্থলটি EF এর একটি ফিল্টার করা ভিউ হওয়া উচিত যা বর্তমান ব্যবহারকারী / ভূমিকার উপর ভিত্তি করে প্রয়োজনীয় ফিলার প্রয়োগ করে ডেটা অ্যাক্সেস রক্ষা করে।

কিন্তু এটি করা ভান্ডারটিকে আরও জটিল করে তোলে কারণ এটি রক্ষণাবেক্ষণের জন্য বিশাল কোড বেসে শেষ হয়। লোকেরা বিভিন্ন ব্যবহারকারীর জন্য বা সত্তার ধরণের সংমিশ্রণের জন্য বিভিন্ন সংগ্রহস্থল তৈরি করে। শুধু এটিই নয়, আমরা প্রচুর ডিটিওও শেষ করি।

উত্তরের উত্তরটি ক্লাস এবং পদ্ধতির পুরো সেট তৈরি না করেই ফিল্টারড রেপোজিটরির উদাহরণ প্রয়োগকরণ। এটি সরাসরি প্রশ্নের উত্তর নাও দিতে পারে তবে এটি একটি উত্স থেকে কার্যকর হতে পারে।

দাবি অস্বীকার: আমি সত্তা REST এসডিকে লেখক।

http://entityrestsdk.codeplex.com

উপরের কথা মাথায় রেখে, আমরা একটি এসডিকে তৈরি করেছি যা সিকিউরিটি কনটেক্সট ভিত্তিক ফিল্টার করা ভিউয়ের সংগ্রহস্থল তৈরি করে যা সিআরইউডি অপারেশনের জন্য ফিল্টার ধারণ করে। এবং মাত্র দুটি ধরণের বিধিগুলি যে কোনও জটিল ক্রিয়াকে সহজ করে দেয় simp প্রথমটি হ'ল সত্তায় অ্যাক্সেস এবং অন্যটি হ'ল সম্পত্তির জন্য পড়ুন / লেখার নিয়ম।

সুবিধাটি হ'ল, আপনি ব্যবসায়ের লজিক বা বিভিন্ন ব্যবহারকারীর জন্য স্টোর পুনরায় লিখবেন না, আপনি কেবল তাদের ব্লক বা অ্যাক্সেস মঞ্জুর করেন।

public class DefaultSecurityContext : BaseSecurityContext {

  public static DefaultSecurityContext Instance = new DefaultSecurityContext();

  // UserID for currently logged in User
  public static long UserID{
       get{
             return long.Parse( HttpContext.Current.User.Identity.Name );
       }
  }

  public DefaultSecurityContext(){
  }

  protected override void OnCreate(){

        // User can access his own Account only
        var acc = CreateRules<Account>();

        acc.SetRead( y => x=> x.AccountID == UserID ) ;
        acc.SetWrite( y => x=> x.AccountID == UserID );

        // User can only modify AccountName and EmailAddress fields
        acc.SetProperties( SecurityRules.ReadWrite, 
              x => x.AccountName,
              x => x.EmailAddress);

        // User can read AccountType field
        acc.SetProperties<Account>( SecurityRules.Read, 
              x => x.AccountType);

        // User can access his own Orders only
        var order = CreateRules<Order>();
        order.SetRead( y => x => x.CustomerID == UserID );

        // User can modify Order only if OrderStatus is not complete
        order.SetWrite( y => x => x.CustomerID == UserID 
            && x.OrderStatus != "Complete" );

        // User can only modify OrderNotes and OrderStatus
        order.SetProperties( SecurityRules.ReadWrite, 
              x => x.OrderNotes,
              x => x.OrderStatus );

        // User can not delete orders
        order.SetDelete(order.NotSupportedRule);
  }
}

এই লিনকিউ বিধিগুলি প্রতিটি ক্রিয়াকলাপের জন্য সেভচেনজ পদ্ধতিতে ডেটাবেসের বিরুদ্ধে মূল্যায়ন করা হয় এবং এই বিধিগুলি ডাটাবেসের সামনে ফায়ারওয়াল হিসাবে কাজ করে।


4
ডিবি-র বিরুদ্ধে ইউনিট পরীক্ষার অর্থ আপনার পরীক্ষার জন্য অতিরিক্ত বাহ্যিক প্রয়োজন। যদি সেই ডিবি ডাউন থাকে, বা ডেটা সাফ হয়ে যায়, বা সেই ডিবি-তে কিছু হয় তবে আপনার পরীক্ষাগুলি ব্যর্থ হবে। এটি পছন্দসই নয়। আইপোজারেবলকে প্রকাশ করে এমন স্টোরগুলি সেটআপ করতে প্রায় 2 মিনিট সময় নেয়। এখানে কোনও সময় নষ্ট হয় না। ডিআই আপনাকে দীর্ঘ সময় নিয়েছিল কেন? এই সমস্ত মিনিট লাগে। আমি বলব যে এগুলি সমস্ত আমার পরিষেবা স্তরে আমার জটিল প্রশ্নগুলির ইউনিট পরীক্ষার জন্য দুর্দান্ত কাজ করেছে। এটি সংযোগের জন্য একটি ডেটাবেস প্রয়োজন হয় না খুব সুন্দর ছিল। নুগেট থেকে একটি উপহাসের কাঠামো পাওয়া প্রায় এক মিনিট সময় নিয়েছিল। এই স্টাফ কোনও সময় লাগে না।
ব্যবহারকারী 441521

@ ব্যবহারকারী441521 আইকোয়্যারেবল 2 মিনিটের সাথে সেটআপ করার জন্য রিপোজিটরিগুলি? আপনি কোন পৃথিবীতে বাস করছেন, আমাদের লাইভ সাইটে প্রতিটি এসপ নেটওয়ারের অনুরোধটি মিলি সেকেন্ডের মধ্যে দেওয়া হয়। ঠাট্টা করা এবং ফেকিং ইত্যাদি কোডে কোডের আরও জটিলতা যুক্ত করে, এটির পুরো সময় অপচয়। ইউনিটকে ব্যবসায় যুক্তিযুক্ত একক হিসাবে সংজ্ঞায়িত না করা হলে ইউনিট পরীক্ষাগুলি অকেজো।
আকাশ কাভা

7

কোন পদ্ধতিটি সঠিক তা নিয়ে প্রচুর বিতর্ক রয়েছে, সুতরাং উভয়টি গ্রহণযোগ্য হিসাবে আমি এটিকে দেখি তাই আমি কোনটি সবচেয়ে বেশি পছন্দ করি তা ব্যবহার করি (কোনটি ভাণ্ডার নয়, ইউওডাব্লু)।

EF- এ ইউওডাব্লু DbContext এর মাধ্যমে প্রয়োগ করা হয় এবং DbSets হ'ল সংগ্রহস্থল।

কীভাবে ডেটা লেয়ার দিয়ে কাজ করবেন আমি সরাসরি ডিবি কনটেক্সট অবজেক্টে কাজ করি, জটিল প্রশ্নের জন্য আমি পুনরায় ব্যবহার করা যেতে পারে এমন প্রশ্নের জন্য এক্সটেনশন পদ্ধতি তৈরি করব।

আমি বিশ্বাস করি যে সিইউডি অপারেশনগুলি কীভাবে বিমূর্ত করা খারাপ, সে সম্পর্কে আয়েনদেরও কিছু পোস্ট রয়েছে।

আমি সর্বদা একটি ইন্টারফেস তৈরি করি এবং আমার প্রসঙ্গটি এর উত্তরাধিকার সূত্রে পাই যাতে আমি ডিআই-র জন্য একটি আইওসি ধারক ব্যবহার করতে পারি।


সুতরাং এক্সটেনশন পদ্ধতি, তারা কতটা বিস্তৃত? আসুন বলুন যে আমার এক্সটেনশনে আমাকে অন্য সত্তার অবস্থা পাওয়া উচিত? এটি এখনই আমার সবচেয়ে বড় উদ্বেগ। আপনি কিছু বাড়ানোর পদ্ধতির উদাহরণ দেখাচ্ছে আপত্তি?
দেজন.এস

ayende.com/blog/153473/… এবং ayende.com/blog/153569/… । (এগুলি একটি # p
জোশ

এটির এনহাইবারনেট ভিত্তিক। আপনি কি EF ব্যবহার করে কোন উদাহরণ পেয়েছেন? এবং আবার যখন আমাকে অন্য সত্তাকে কল করতে হবে তবে স্থির এক্সটেনশন পদ্ধতিতে এটি কীভাবে সেরা হয়?
দেজন.এস

4
আপনার ডোমেন অবজেক্টের কোনও সম্পত্তি আপনার ডেটাবেজে সংরক্ষণ না করে এমন ডেটা দ্বারা হাইড্রেট করার দরকার না হওয়া পর্যন্ত এটি সবই ভাল এবং ভাল; অথবা আপনাকে এমন কোনও প্রযুক্তিতে যেতে হবে যা আপনার ফুলে যাওয়া ওআরএম থেকে বেশি পারফরম্যান্ট। ওওপিএস! একটি ওআরএম কেবল কোনও সংগ্রহস্থলের প্রতিস্থাপন নয়, এটি একটির বাস্তবায়নের বিশদ।
সিডিএইচ

2

EF- র মাধ্যমে সর্বাধিক প্রয়োগ করা হ'ল কোনও সংগ্রহস্থল বিন্যাস নয়। এটি একটি মুখোমুখি প্যাটার্ন (ইএফ পদ্ধতিতে কলগুলি সরল, সংস্করণগুলি ব্যবহার করা সহজ) হিসাবে বিমূর্ত করা।

EF হ'ল রেপোজিটরি প্যাটার্ন প্রয়োগ করে (এবং পাশাপাশি ওয়ার্ক প্যাটার্নের ইউনিট)। এটি হ'ল EF হ'ল ডেটা অ্যাক্সেস লেয়ারটি বিমূর্ত করে দেয় যাতে ব্যবহারকারীর ধারণা না থাকে যে তারা এসকিউএল সার্ভারের সাথে কীভাবে কাজ করছেন।

এবং তারপরে, ইএফ-র বেশিরভাগ "ভান্ডারগুলি" খুব ভাল ফ্যাকাদেও না কারণ তারা কেবল ইএফ-তে একক পদ্ধতিতে এমনকি একই স্বাক্ষর থাকার বিন্দুতে ম্যাপ করে।

EF- র উপর তথাকথিত "সংগ্রহশালা" প্যাটার্ন প্রয়োগের জন্য দুটি কারণ হ'ল সহজ পরীক্ষার অনুমতি দেওয়া এবং এটিতে "ক্যানড" কলগুলির একটি উপসেট স্থাপন করা। তাদের মধ্যে খারাপ নয়, তবে স্পষ্টতই কোনও সংগ্রহশালা নয়।


1

লিঙ্ক আজকালকার 'রিপোজিটরি'।

আইসেশন + লিনক হ'ল ইতিমধ্যে সংগ্রহস্থল এবং আপনার কোনও GetXByYপদ্ধতি বা QueryData(Query q)সাধারণীকরণের প্রয়োজন নেই । ডাল ব্যবহারে কিছুটা ভৌতিক হওয়ার কারণে আমি এখনও সংগ্রহস্থল ইন্টারফেসটি পছন্দ করি। (রক্ষণাবেক্ষণের দৃষ্টিকোণ থেকে আমাদের এখনও নির্দিষ্ট ডেটা অ্যাক্সেস ইন্টারফেসের কিছুটা মুখোমুখি থাকতে হবে)।

এখানে আমরা যে সংগ্রহস্থল ব্যবহার করি তা এখানে রয়েছে - এটি আমাদেরকে নিবারনেটের প্রত্যক্ষ ব্যবহার থেকে দূরে সরিয়ে দেয়, তবে লিনাক ইন্টারফেস সরবরাহ করে (ব্যতিক্রমী ক্ষেত্রে আইসেশন অ্যাক্সেস হিসাবে, যা শেষ পর্যন্ত রিফ্যাক্টরের সাপেক্ষে)।

class Repo
{
    ISession _session; //via ioc
    IQueryable<T> Query()
    {
        return _session.Query<T>();
    }
}

আপনি পরিষেবা স্তর জন্য কি করবেন?
দেজন.এস

কন্ট্রোলাররা কেবল-পঠনযোগ্য ডেটাগুলির জন্য রেপোকে জিজ্ঞাসা করে, কিছু অতিরিক্ত স্তর কেন যুক্ত করবেন? অন্য সম্ভাবনাটি "কন্টেন্ট সার্ভিস" ব্যবহার করছে যা আরও বেশি করে একটি পরিষেবা-স্তরের-সংগ্রহস্থল: গেটএক্সবিওয়াই, ইত্যাদি ইত্যাদি প্রবণতা হিসাবে থাকে। পরিবর্তনের ক্রিয়াকলাপগুলির জন্য - অ্যাপ্লিকেশন পরিষেবাগুলি কেবল ব্যবহারের ক্ষেত্রে বিমূর্ততা রয়েছে - তারা বিএল এবং
নিখরচায়

আমি ব্যবসায়ের যুক্তির জন্য পরিষেবা স্তর করতে ব্যবহৃত হয়েছি। আমি সত্যিই নিশ্চিত নই যে আপনি কন্টেন্ট সার্ভিসের সাহায্যে যা অনুসরণ করি তা দয়া করে বিস্তারিত। "পরিষেবা স্তর" হিসাবে সহায়ক ক্লাসগুলি করা কি খারাপ অভ্যাস হবে?
দেজন.এস

'পরিষেবা স্তর' দ্বারা আমি "অ্যাপ্লিকেশন পরিষেবা" বোঝাতে চাইছি। তারা সংগ্রহস্থল এবং ডোমেন স্তরের যে কোনও পাবলিক অংশ ব্যবহার করতে পারে। "পরিষেবা স্তর" খারাপ অনুশীলন নয়, তবে আমি কেবল তালিকা <এক্স> ফলাফল সরবরাহের জন্য এক্স সার্ভিস ক্লাস করা এড়াতে চাই। মন্তব্যের ক্ষেত্রটি বিশদগুলিতে পরিষেবাদি বর্ণনা করতে খুব ছোট বলে মনে হচ্ছে, দুঃখিত।
মিকালাই

কী যদি, একটি কার্টের গণনা বলতে দেয় এবং একটি গণনা করার জন্য আপনার অ্যাপ্লিকেশন সেটিংসের প্যারামিটার এবং নির্দিষ্ট গ্রাহক পরামিতিগুলি নেওয়া দরকার এবং এটি অ্যাপ্লিকেশনের বেশ কয়েকটি স্থানে পুনরায় ব্যবহৃত হয়। কীভাবে আপনি এই পরিস্থিতি সামাল দেন? সহায়ক শ্রেণি বা আবেদন পরিষেবা?
দেজন.এস

1

সংগ্রহস্থলের প্রয়োগ এই সময়ে (অথবা তবে এক তা চয়ন একে ডাকতে) আমার অধ্যবসায় স্তর দূরে সংক্ষেপ সম্পর্কে বেশিরভাগই হয়।

আমি এটিকে ক্যোয়ারী অবজেক্টগুলির সাথে একত্রে ব্যবহার করি যাতে আমার অ্যাপ্লিকেশনগুলিতে কোনও বিশেষ প্রযুক্তির সাথে আমার মিলিত না হয়। এবং এটি অনেক পরীক্ষা সহজ করে তোলে।

সুতরাং, আমি আছে ঝোঁক

public interface IRepository : IDisposable
{
    void Save<TEntity>(TEntity entity);
    void SaveList<TEntity>(IEnumerable<TEntity> entities);

    void Delete<TEntity>(TEntity entity);
    void DeleteList<TEntity>(IEnumerable<TEntity> entities);

    IList<TEntity> GetAll<TEntity>() where TEntity : class;
    int GetCount<TEntity>() where TEntity : class;

    void StartConversation();
    void EndConversation();

    //if query objects can be self sustaining (i.e. not need additional configuration - think session), there is no need to include this method in the repository.
    TResult ExecuteQuery<TResult>(IQueryObject<TResult> query);
}

প্রতিনিধি হিসাবে কলব্যাকের সাহায্যে অ্যাসিঙ্ক পদ্ধতিগুলি সম্ভবত যুক্ত করুন। রেপো সাধারণভাবে প্রয়োগ করা সহজ , তাই আমি অ্যাপ্লিকেশন থেকে অ্যাপ্লিকেশন পর্যন্ত প্রয়োগের কোনও লাইন স্পর্শ করতে পারছি না। ঠিক আছে, এনএইচ ব্যবহার করার সময় এটি সত্য, আমি এটিএফ দিয়েও করেছি, তবে আমাকে ইএফকে ঘৃণা করেছিলাম। ৪) কথোপকথনটি একটি লেনদেনের শুরু। কয়েকটি ক্লাস যদি সংগ্রহস্থলের উদাহরণটি ভাগ করে দেয় তবে খুব শীতল। এছাড়াও, এনএইচের জন্য, আমার বাস্তবায়নের একটি রেপো একটি সেশনের সমান যা প্রথম অনুরোধে খোলা হয়।

তারপরে ক্যোয়ারী অবজেক্টস

public interface IQueryObject<TResult>
{
    /// <summary>Provides configuration options.</summary>
    /// <remarks>
    /// If the query object is used through a repository this method might or might not be called depending on the particular implementation of a repository.
    /// If not used through a repository, it can be useful as a configuration option.
    /// </remarks>
    void Configure(object parameter);

    /// <summary>Implementation of the query.</summary>
    TResult GetResult();
}

কনফিগার করার জন্য আমি কেবলমাত্র আইশনে পাস করার জন্য এনএইচ ব্যবহার করি। ইএফ-তে কম-বেশি কোনও ধারণা নেই।

একটি উদাহরণ ক্যোয়ারী হবে .. (এনএইচ)

public class GetAll<TEntity> : AbstractQueryObject<IList<TEntity>>
    where TEntity : class
{
    public override IList<TEntity> GetResult()
    {
        return this.Session.CreateCriteria<TEntity>().List<TEntity>();
    }
}

একটি EF ক্যোয়ারী করতে আপনার অ্যাবস্ট্রাক্ট বেসে প্রসঙ্গ থাকতে হবে, সেশন নয়। তবে অবশ্যই আইএফসি একই হবে।

এইভাবে কোয়েরিগুলি নিজেরাই এনপ্যাপুলেটেড, এবং সহজেই টেস্টযোগ্য। সর্বোপরি, আমার কোডটি কেবল ইন্টারফেসের উপর নির্ভর করে। সবকিছু খুব পরিষ্কার। ডোমেন (ব্যবসায়ের) অবজেক্টগুলি ঠিক এটি, যেমন কোনও সক্রিয় রেকর্ড প্যাটার্ন ব্যবহার করার সময় কোনও দায়বদ্ধতার মিশ্রণ নেই যা খুব সহজেই পরীক্ষাযোগ্য হয় এবং ডোমেন অবজেক্টে ডেটা অ্যাক্সেস (ক্যোয়ারী) কোডের মিশ্রণ করে এবং তা করায় উদ্বেগের মিশ্রণ হয় (অবজেক্টটি যা নিয়ে আসে) নিজেই ??)। প্রত্যেকে ডেটা স্থানান্তরের জন্য পোকো তৈরি করতে এখনও অবাধ।

সব মিলিয়ে, আমি কল্পনাও করতে পারি না এমন কিছু হারিয়ে এই কোডের সাথে প্রচুর কোড পুনরায় ব্যবহার এবং সরলতা সরবরাহ করা হয়। কোন ধারনা?

এবং আয়েন্দিকে তাঁর দুর্দান্ত পোস্ট এবং অব্যাহত উত্সর্গের জন্য অনেক ধন্যবাদ। এটি তার ধারণা এখানে (ক্যোয়ারী অবজেক্ট), আমার নয়।


4
অধ্যবসায় সত্তা (আপনার POCOs) ব্যবসায় / ডোমেন সত্তা নয়। এবং সংগ্রহস্থলের উদ্দেশ্য অধ্যবসায় থেকে ব্যবসায় (আর কোনও) স্তরকে ডিক্লোল করা ple
মাইকএসডব্লিউ

আমি মিলন দেখতে ব্যর্থ। কিছুটা পোকার অংশে একমত, কিন্তু যত্ন নেই। আপনাকে 'জেনুইন' পোকো রাখা থেকে বিরত রাখার কিছুই নেই এবং এখনও এই পদ্ধতির ব্যবহার করতে পারেন।
h.alex

4
সত্তাগুলিকে মোটেও বোবা POCO হতে হবে না। প্রকৃতপক্ষে, সত্তাগুলিতে ব্যবসায়িক যুক্তিকে মডেলিং করা হ'ল ডিডিডি জনতা সর্বদা যা করে। এই স্টাইলের বিকাশটি এনএইচ বা ইএফের সাথে খুব ভাল মিশ্রিত হয়েছে।
ক্রিস

1

আমার জন্য, এটি একটি সহজ সিদ্ধান্ত, তুলনামূলকভাবে কয়েকটি কারণ সহ। কারণগুলি হ'ল:

  1. ভান্ডারগুলি ডোমেন ক্লাসের জন্য।
  2. আমার কিছু অ্যাপ্লিকেশনগুলিতে, ডোমেন ক্লাসগুলি আমার অধ্যবসায়ের (ডিএএল) ক্লাসগুলির মতো, অন্যথায় সেগুলি হয় না।
  3. যখন তারা একই হয়, ইএফ আমাকে ইতিমধ্যে সংগ্রহস্থল সরবরাহ করে।
  4. ইএফ অলস লোডিং এবং আইকিউয়েরেবল সরবরাহ করে। আমি এগুলি পছন্দ করি।
  5. EF- এর উপর বিমূর্ত / 'ফেসেডিং' / পুনরায় প্রয়োগকরণের সংগ্রহের অর্থ সাধারণত অলস এবং আইকুয়েরেবলের ক্ষতি

সুতরাং, যদি আমার অ্যাপ্লিকেশনটি # 2, আলাদা ডোমেন এবং ডেটা মডেলগুলিকে ন্যায়সঙ্গত করতে না পারে তবে আমি সাধারণত # 5 নিয়ে বিরক্ত করব না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.