সংগ্রহস্থলগুলি কি আইকোয়ারিযোগ্য ফিরে আসতে হবে?


66

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

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

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

আমি সর্বদা কল করেছি AsEnumerableবা ToArrayআমার প্রতিটি লিনকিউ এক্সপ্রেশনের শেষে রেপোজিটারি কোড ছাড়ার আগে ডাটাবেস হিট হয়েছে তা নিশ্চিত করার জন্য।

আমি ভাবছি যদি IQueryableকোনও ডেটা স্তরের জন্য বিল্ডিং ব্লক হিসাবে ফিরে আসা কার্যকর হতে পারে। এর চেয়েও বড় আকারের গড়ে তুলতে আমি একটি রিপোজিটরির সাথে অন্য একটি সংগ্রহস্থলের কল দিয়ে বেশ কিছু অমিতব্যয়ী কোড দেখেছি IQueryable


যদি ডিবি ডিফারেন্ট ক্যোয়ারী কার্য সম্পাদনের সময় বনাম কোয়েরি নির্মাণের সময় না পাওয়া যায় তবে কী পার্থক্য হবে? কনজিউমিং কোডে পরিস্থিতি নির্বিশেষে মোকাবেলা করতে হবে।
স্টিভেন এভার্স 21

আকর্ষণীয় প্রশ্ন, তবে সম্ভবত উত্তর দেওয়া শক্ত হবে be একটি সাধারণ অনুসন্ধান আপনার প্রশ্ন সম্পর্কে মোটামুটি উত্তপ্ত বিতর্ক দেখায়: duckduckgo.com/?q=repository+return+iqueryable
Corbin March

6
আপনার ক্লায়েন্টদের লিনক ক্লজগুলি যুক্ত করতে মুলতুবি করতে হবে যা মুলতুবি কার্যকরকরণ থেকে উপকৃত হতে পারে তা এই সবের মধ্যে নেমে আসে। যদি তারা whereএকটি বিলম্বিত একটি শৃঙ্খলা যুক্ত করে IQueryable, আপনি কেবল তারের উপরের তথ্য পাঠাতে হবে , পুরো ফলাফল সেট নয় set
রবার্ট হার্ভে

আপনি যদি সংগ্রহস্থল প্যাটার্ন ব্যবহার করছেন - না, আপনার আইকোয়ারিযোগ্য ফিরে আসা উচিত নয়। এখানে একটি সুন্দর কারণ
অ্যারিস ল্যাপসা

1
@ স্টিভেভার্স একটি বিশাল পার্থক্য আছে। যদি আমার সংগ্রহস্থলে কোনও ব্যতিক্রম ছুঁড়ে ফেলা হয়, তবে আমি এটিকে ডেটা-স্তর-নির্দিষ্ট ব্যতিক্রম প্রকারের সাথে মোড়াতে পারি। যদি এটি পরে ঘটে থাকে তবে আমাকে সেখানে মূল ব্যতিক্রম ক্যাপচার করতে হবে। আমি ব্যতিক্রমের উত্সের কাছাকাছি, সম্ভবত এটির কারণটি আমি জানতে পারব। অর্থপূর্ণ ত্রুটি বার্তা তৈরি করার জন্য এটি গুরুত্বপূর্ণ। আইএমএইচও, কোনও EF- নির্দিষ্ট ব্যতিক্রমকে আমার ভান্ডারটি ছেড়ে দেওয়ার অনুমতি দেওয়া এনক্যাপসুলেশন লঙ্ঘন।
ট্র্যাভিস পার্কগুলি

উত্তর:


47

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

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

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

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

সুতরাং দলের উপর নির্ভর করে, তাদের অভিজ্ঞতা, অ্যাপের আকার, সামগ্রিক স্তর এবং আর্কিটেকচার ... এটি নির্ভর করে: - \


নোট করুন যে আপনি যদি এটির জন্য কাজ করতে চান তবে আপনার আইকোয়ারিযোগ্যকে ফিরিয়ে দিতে পারেন, যার ফলস্বরূপ ডিবি কল করে তবে লেয়ারিং এবং আচরণগত নিয়ন্ত্রণগুলি যুক্ত করে।
PSr

1
@ পিএসআর আপনি এর অর্থ কী বলতে পারবেন?
ট্র্যাভিস পার্কগুলি

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

2
মনে রাখবেন যে আপনি যখন আইকুয়েবিয়েলগুলি না ফেরান, তবুও আপনি কেবল Expression<Func<Foo,bool>>আপনার পদ্ধতিতে একটি পাস করে অনেকগুলি পদ্ধতি (গেটএলএকটিভ আইটেমস, গেটএলননঅ্যাক্টিভ আইটেম, ইত্যাদি) তৈরি করতে বাধা দিতে পারেন । এই প্যারামিটারগুলি Whereসরাসরি পদ্ধতিতে পৌঁছে দেওয়া যেতে পারে , এইভাবে গ্রাহকরা আইকুয়েরেবল <Foo> এ সরাসরি অ্যাক্সেসের প্রয়োজন ছাড়াই তাদের ফিল্টারটি চয়ন করতে সক্ষম করে।
ফ্ল্যাটার

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

29

পাবলিক ইন্টারফেসে আইকিউয়ারেবলকে প্রকাশ করা ভাল অনুশীলন নয়। কারণটি মৌলিক: আপনি আইকিউয়ারেবল উপলব্ধিটি যেমনটি বলা যায় তেমন সরবরাহ করতে পারবেন না।

পাবলিক ইন্টারফেস হল সরবরাহকারী এবং ক্লায়েন্টদের মধ্যে একটি চুক্তি। এবং বেশিরভাগ ক্ষেত্রে সম্পূর্ণ বাস্তবায়নের প্রত্যাশা রয়েছে। আইকিউয়েরেবল একটি প্রতারণা:

  1. আইকিউয়েরেবল কার্যকর করা প্রায় অসম্ভব। এবং বর্তমানে কোনও সঠিক সমাধান নেই। এমনকি সত্তা ফ্রেমওয়ার্ক প্রচুর আছে UnsupportedExceptions
  2. আজ ক্যোয়ারিয়েবল সরবরাহকারীদের অবকাঠামোগত উপর বৃহত নির্ভরতা রয়েছে। শেয়ারপয়েন্টের নিজস্ব আংশিক বাস্তবায়ন রয়েছে এবং আমার এসকিউএল সরবরাহকারীর স্বতন্ত্র আংশিক বাস্তবায়ন রয়েছে।

সংগ্রহস্থল প্যাটার্ন আমাদের লেয়ারিং দ্বারা স্পষ্ট প্রতিনিধিত্ব করে, এবং, সবচেয়ে গুরুত্বপূর্ণ, বাস্তবায়নের স্বাধীনতা। সুতরাং আমরা ভবিষ্যতের ডেটা উত্সে পরিবর্তন করতে পারি।

প্রশ্নটি হল " ডেটা উত্সের বিকল্পের কি কোনও সম্ভাবনা আছে? "

আগামীকাল যদি ডেটার অংশটি এসএপি পরিষেবাগুলিতে, নোএসকিউএল ডেটা বেসে বা কেবল পাঠ্য ফাইলগুলিতে স্থানান্তরিত করা যায় তবে আমরা কি আইকিউয়েরেবল ইন্টারফেসের যথাযথ প্রয়োগের গ্যারান্টি দিতে পারি?

( কেন এটি খারাপ অনুশীলন তা সম্পর্কে আরও ভাল বিষয়)


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

1
আপনাকে ধন্যবাদ লার্সভিক্লুন্ড, উত্তরটি উদাহরণ এবং সমস্যার বিবরণ দিয়ে আপডেট হয়েছে
আর্ট্রু

19

বাস্তবসম্মতভাবে, যদি আপনি পিছিয়ে দেওয়া কার্যকর করতে চান তবে আপনি তিনটি বিকল্প পেয়েছেন:

  • এটি এইভাবে করুন - একটি এক্সপোজ IQueryable
  • একটি কাঠামো কার্যকর করুন যা নির্দিষ্ট ফিল্টার বা "প্রশ্ন" এর জন্য নির্দিষ্ট পদ্ধতি প্রকাশ করে। ( GetCustomersInAlaskaWithChildren, নীচে)
  • একটি কাঠামো প্রয়োগ করুন যা দৃ strongly়ভাবে টাইপযুক্ত ফিল্টার / সাজানো / পৃষ্ঠা API প্রকাশ করে এবং IQueryableঅভ্যন্তরীণভাবে বিল্ড করে ।

আমি তৃতীয়টিকে পছন্দ করি (যদিও আমি সহকর্মীদেরও দ্বিতীয়টি বাস্তবায়নে সহায়তা করেছি) তবে অবশ্যই এতে কিছু সেটআপ এবং রক্ষণাবেক্ষণ জড়িত রয়েছে। (উদ্ধার করার জন্য টি 4!)

সম্পাদনা : আমি যা বলছি তার চারপাশে বিভ্রান্তি দূর করার জন্য, আইকুয়েরেবল থেকে চুরি হওয়া নিম্নলিখিত উদাহরণটি বিবেচনা করুন আপনার কুকুরটিকে মেরে ফেলতে পারেন, আপনার স্ত্রীকে চুরি করতে পারেন, আপনার ইচ্ছাকে বেঁচে রাখতে পারেন ইত্যাদি etc.

আপনি যেখানে এমন কিছু প্রকাশ করবেন সেই দৃশ্যে:

public class CustomerRepo : IRepo 
{ 
     private DataContext ct; 
     public Customer GetCustomerById(int id) { ... } 
     public Customer[] GetCustomersInAlaskaWithChildren() { ... } 
} 

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

এর মতো পদ্ধতির আরেকটি সুবিধা হ'ল তারা পোকো ক্লাস হওয়ায় এই ভান্ডারটি কোনও ওয়েব বা ডাব্লুসিএফ পরিষেবার পিছনে থাকতে পারে; এটি এজেএক্স বা অন্যান্য কলারদের কাছে প্রকাশ করা যেতে পারে যারা লিনকিউ সম্পর্কে প্রথম জিনিস জানেন না।


4
সুতরাং আপনি কোয়েরি এপিআই .NET এর অন্তর্নির্মিত বিকল্পের জন্য কোয়েরি এপিআই তৈরি করতে চান?
মাইকেল ব্রাউন

4
আমার কাছে বেশ অর্থহীন শোনায়
২zz

7
এবং আমার উত্তর - - এই প্রশ্নের বিন্দু @MikeBrown আপনি এক্সপোজ করতে চান আচরণ বা সুবিধার এর IQueryable প্রকাশক ছাড়া IQueryableনিজেই । বিল্ট-ইন এপিআই দিয়ে আপনি কীভাবে তা করতে যাচ্ছেন?
গ্যালাকটিক

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

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

8

সত্যিই কেবল একটি বৈধ উত্তর আছে: এটি কীভাবে সংগ্রহস্থলটি ব্যবহার করা হবে তার উপর নির্ভর করে।

এক পর্যায়ে আপনার সংগ্রহস্থলটি একটি ডিবিসিওন্টেক্সটের চারপাশে খুব পাতলা র‌্যাপার হয় যাতে আপনি একটি ডেটাবেস-চালিত অ্যাপের আশেপাশে টেস্টাবিলিটির ঝাঁকুনি ইনজেকশন করতে পারেন। সত্যিকার অর্থে কোন বাস্তব প্রত্যাশা নেই যে এটির পিছনে লিনকিউ বন্ধুত্বপূর্ণ ডিবি ব্যতিরেকে সংযোগ বিচ্ছিন্নভাবে ব্যবহার করা যেতে পারে কারণ আপনার সিআরইউডি অ্যাপ্লিকেশনটির এটির আর প্রয়োজন নেই। তারপরে নিশ্চিত, আইকোয়ারিযোগ্য ব্যবহার করবেন না কেন? আপনি বেশিরভাগ সুবিধাগুলি [পড়ুন: বিলম্বিত মৃত্যুদণ্ড] পেয়ে যাওয়ায় আমি সম্ভবত আইমুনামেবলকে পছন্দ করব এবং এটি অপ্রয়োজনীয় মনে হয় না।

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


6
প্রত্যাবর্তনের বিষয়ে IEnumerable, এটি লক্ষ্য করা গুরুত্বপূর্ণ যে এটির ((IEnumerable<T>)query).LastOrDefault()চেয়ে পৃথক query.LastOrDefault()(অনুমান করা queryহয় একটি IQueryable)। সুতরাং, IEnumerableযদি আপনি যাইহোক সমস্ত উপাদানগুলির মাধ্যমে পুনরাবৃত্তি করতে যাচ্ছেন তবে এটি কেবল ফিরে আসার অর্থবোধ করে।
লু

7
 > Should Repositories return IQueryable?

কোন কোন সহজ উপায় ডাটাবেসের বা অন্যান্য IQueryable প্রদানকারীর থেকে বিচ্ছিন্নতা আপনার businesslogic (= সংগ্রহস্থলের-ভোক্তা) পরীক্ষা করার জন্য একটি উপহাস সংগ্রহস্থলের তৈরি করতে না থাকায় আপনি testdriven উন্নয়ন / unittesting করতে চান।


6

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


6

আমি যেমন পছন্দ মত মুখোমুখি হয়েছি।

সুতরাং, আসুন ইতিবাচক এবং নেতিবাচক দিকগুলি সংক্ষেপে বলা যাক:

পজিটিভ:

  • নমনীয়তা. এটি নিশ্চিতভাবে নমনীয় এবং সুবিধাজনক যে ক্লায়েন্টের পক্ষে কেবলমাত্র একটি সংগ্রহস্থল পদ্ধতিতে কাস্টম ক্যোয়ারি তৈরি করতে অনুমতি দেওয়া

ঋণাত্মক সম্মাননা:

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

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


5

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

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

কোনও প্রকল্পের প্রথম কয়েকটি পুনরাবৃত্তির জন্য, আইকোয়ারিকে সর্বজনীনভাবে ভান্ডারটিতে প্রকাশ করা দ্রুত বৃদ্ধির সুযোগ দেয়। প্রথম সম্পূর্ণ প্রকাশের আগে, আমি ক্যোয়ারী অপারেশনটিকে ব্যক্তিগত বা সুরক্ষিত করে বুনো অনুসন্ধানগুলি এক ছাদের নীচে আনার পরামর্শ দেব recommend


4

আমি যা দেখেছি (এবং যা আমি নিজেকে বাস্তবায়ন করছি) তা হ'ল:

public interface IEntity<TKey>
{
    TKey Id { get; set; }
}

public interface IRepository<TEntity, in TKey> where TEntity : IEntity<TKey>
{
    void Create(TEntity entity);
    TEntity Get(TKey key);
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> GetAll(Expression<Func<TEntity, bool>> expression);
    void Update(TEntity entity);
    void Delete(TKey id);
}

এটি আপনাকে যা করতে দেয় তা হ'ল কোনও লিনকিউ ব্যবসা প্রকাশ IQueryable.Where(a => a.SomeFilter)না concreteRepo.GetAll(a => a.SomeFilter)করেই আপনার রেপোতে কোনও ক্যোয়ারী করার নমনীয়তা থাকা ।

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