সত্তা ফ্রেমওয়ার্ক: এক ডাটাবেস, একাধিক ডিবি কনটেক্সটস। এটা কি একটি খারাপ ধারণা? [বন্ধ]

Question

আজ অবধি আমার ধারণাটি DbContextহ'ল একটি আপনার ডেটাবেসকে উপস্থাপন করার জন্য বোঝানো হয়েছে, এবং এইভাবে, যদি আপনার অ্যাপ্লিকেশনটি একটি ডাটাবেস ব্যবহার করে তবে আপনি কেবল একটি চাইবেন DbContext।

তবে কিছু সহকর্মী কার্যকরী অঞ্চলগুলি পৃথক DbContextশ্রেণিতে বিভক্ত করতে চান ।

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

সুতরাং আমি খুঁজছি:

ক) কেন এটি একটি খারাপ ধারণা হতে পারে তার দৃ concrete় উদাহরণ;

খ) আশ্বাস দেয় যে এটি সমস্ত ঠিক কাজ করবে।

Comments

আমার উত্তর দেখুন: স্ট্যাকওভারফ্লো.com

— মোহসেন আলিখানি

Answer 1

একক ডাটাবেসের জন্য আপনার একাধিক প্রসঙ্গ থাকতে পারে। উদাহরণস্বরূপ এটি কার্যকর হতে পারে যদি আপনার ডাটাবেসে একাধিক ডাটাবেস স্কিম থাকে এবং আপনি তাদের প্রত্যেককে আলাদা স্ব-অন্তর্ভুক্ত অঞ্চল হিসাবে পরিচালনা করতে চান।

সমস্যাটি যখন আপনি নিজের ডেটাবেস তৈরির জন্য কোডটি প্রথমে ব্যবহার করতে চান - আপনার আবেদনে কেবলমাত্র একক প্রসঙ্গ এটি করতে পারে। এর কৌশলটি হ'ল আপনার সমস্ত সত্তা সম্বলিত একটি অতিরিক্ত প্রসঙ্গ যা কেবলমাত্র ডাটাবেস তৈরির জন্য ব্যবহৃত হয়। আপনার সত্তাগুলির কেবলমাত্র সাবসেট রয়েছে এমন আপনার আসল অ্যাপ্লিকেশন প্রসঙ্গে অবশ্যই ডাটাবেস প্রারম্ভকটি বাতিল করতে হবে to

একাধিক প্রসঙ্গের প্রকারগুলি ব্যবহার করার সময় আপনি অন্যান্য সমস্যাগুলি দেখতে পাবেন - উদাহরণস্বরূপ ভাগ করা সত্তার প্রকারগুলি এবং তাদের একটি প্রসঙ্গ থেকে অন্য প্রসঙ্গে চলে যাওয়া ইত্যাদি General অতিরিক্ত জটিলতায় খরচ হয়।

Comments

অ্যাপ্লিকেশনটিতে অনেক সত্ত্বা / টেবিল থাকলে অ্যাপ প্রতি একক প্রসঙ্গ ব্যবহার ব্যয়বহুল হতে পারে। এইভাবে স্কিমার উপর নির্ভর করে এটি একাধিক প্রসঙ্গটি বোধ করতে পারে।

— দার্থভেদার

যেহেতু আমি বহুবর্ষের সাবস্ক্রাইব করি না, তাই আমি জুলি লারম্যানের এই দুর্দান্ত নিবন্ধটি ( তার মন্তব্য ) এই প্রশ্ন / উত্তর পরে ভালভাবে লিখেছি তবে এটি খুব উপযুক্ত: আমিএসডিএন.মাইক্রোসফটকম /en-us/magazine/jj883952.aspx

— ডেভ টি।

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

— ফ্রিউইল

সংযোজন, আমি বুঝতে পেরেছিলাম যে আপনি প্রধানমন্ত্রী কনসোলের মাধ্যমে কেবলমাত্র প্রকল্পের অভ্যন্তরের জন্য মাইগ্রেশন সক্ষম করতে পারবেন।

— পাইওটার কুইটেক

@ পাইওট্রকুইটেক নিশ্চিত না যে এটি আপনার মন্তব্য এবং এখনকার মধ্যে পরিবর্তিত হয়েছে তবে Enable-Migrations -ContextTypeName MyContext -MigrationsDirectory Migrations\MyContextMigrationsএখনই কাজ করে।

— জ্যাক

Answer 2

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

আমি আমার ভোটটি ব্যাক আপ করার বাস্তব-অভিজ্ঞতার সাথে ধারণার বিরুদ্ধে যাব।

আমাকে একটি বৃহত অ্যাপ্লিকেশনে নিয়ে আসা হয়েছিল যার একক ডাটাবেসের জন্য পাঁচটি প্রসঙ্গ রয়েছে। শেষ পর্যন্ত, আমরা একটি ব্যতীত সমস্ত প্রসঙ্গটি সরিয়ে দিয়ে শেষ করেছি - একক প্রসঙ্গে ফিরে আসছি।

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

তবে বাস্তবে, আমাদের অ্যাপ্লিকেশনটি বাড়ার সাথে সাথে আমাদের অনেকগুলি সারণী আমাদের বিভিন্ন প্রসঙ্গে সম্পর্ক ভাগ করে নিল। উদাহরণস্বরূপ, প্রসঙ্গ 1-এ টেবিল এ-এর প্রশ্নের জন্যও প্রসঙ্গ 2 তে সারণি বি তে যোগদান করা প্রয়োজন।

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

আমরা আমাদের প্রয়োজনীয় ডেটা পেতে উভয় প্রসঙ্গে জিজ্ঞাসা করার চেষ্টা করেছি। উদাহরণস্বরূপ, আমাদের ব্যবসায়িক যুক্তি প্রাসঙ্গিক 1 এবং এর অর্ধেকটি প্রসঙ্গ 2 থেকে যা প্রয়োজন তার অর্ধেকটি জিজ্ঞাসা করবে This এতে কিছু বড় সমস্যা ছিল। একক প্রসঙ্গের বিরুদ্ধে একটি ক্যোয়ারি করার পরিবর্তে আমাদের বিভিন্ন প্রসঙ্গে একাধিক ক্যোয়ারী করতে হয়েছিল। এটির একটি বাস্তব পারফরম্যান্স পেনাল্টি রয়েছে।

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

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

মাইক্রো-পরিষেবাগুলি সম্পর্কে, একটি একক প্রসঙ্গ এখনও বোধগম্য হয়। যাইহোক, মাইক্রো-পরিষেবাগুলির জন্য, প্রতিটি পরিষেবার নিজস্ব প্রসঙ্গ থাকবে যা কেবলমাত্র সেই পরিষেবার সাথে সম্পর্কিত ডেটাবেস টেবিলগুলিকে অন্তর্ভুক্ত করে। অন্য কথায়, যদি পরিষেবা x 1 এবং 2 টেবিলগুলিতে অ্যাক্সেস করে এবং পরিষেবা y 3 এবং 4 টেবিলগুলিতে অ্যাক্সেস করে তবে প্রতিটি পরিষেবার নিজস্ব স্বতন্ত্র প্রসঙ্গ থাকতে পারে যার মধ্যে সেই পরিষেবার সাথে নির্দিষ্ট সারণী অন্তর্ভুক্ত থাকে।

আমি আপনার চিন্তায় আগ্রহী।

Comments

আমাকে এখানে সম্মত হতে হবে, বিশেষত যখন বিদ্যমান ডাটাবেসটিকে লক্ষ্য করে। আমি এই মুহূর্তে এই সমস্যাটিতে কাজ করছি, এবং এখন পর্যন্ত আমার অন্ত্র অনুভূতিটি হ'ল: ১. একাধিক প্রসঙ্গে একই শারীরিক টেবিল রাখা একটি খারাপ ধারণা। ২. যদি আমরা সিদ্ধান্ত নিতে পারি না যে একটি টেবিলটি একটি প্রসঙ্গে বা অন্য প্রসঙ্গে রয়েছে, তবে দুটি প্রসঙ্গটি যৌক্তিকভাবে আলাদা করার পক্ষে যথেষ্ট স্বতন্ত্র নয়।

— jkerak

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

— নগরহসকি

আমি গভীরভাবে আপনি যে বেদনার মুখোমুখি হয়েছিল তা অনুভব করেছি! : / আমি আরও মনে করি যে একটি প্রসঙ্গ সরলতার জন্য আরও ভাল পছন্দ।

— অহমেট

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

— ব্যারি

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

— সাইমনসন

Answer 3

এই থ্রেডটি স্ট্যাকওভারফ্লোতে সবেমাত্র বুদবুদ হয়ে গেছে এবং তাই আমি আরও একটি "বি) আশ্বাস দিয়েছিলাম যে এটি সব ঠিক হয়ে যাবে" :)

আমি ঠিক এটি ডিডিডি বাউন্ডেড কনটেক্সট প্যাটার্নের মাধ্যমে করছি। আমি আমার বই, প্রোগ্রামিং সত্তা ফ্রেমওয়ার্ক: ডিবি কনটেক্সট এ সম্পর্কে লিখেছি এবং এটি আমার বহুবচন -> http://pluralsight.com/training/Courses/TableOfContents/efarchitecture- এ আমার এক কোর্সের মধ্যে 50 মিনিটের মডিউলটির ফোকাস is

Comments

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

— ভিক্টর রোমিও

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

— জুলি লারম্যান

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

— সহানুভূতিশীল

দুঃখিত, আমি প্রচারের চেষ্টা করছিলাম না, কেবল ওপিকে "আশ্বাস চাই" যোগ করেছিলাম। লাডিসালভ এবং অন্যান্যরা বিশদ সহ দুর্দান্ত কাজ করেছিলেন। সুতরাং আমি কেবল এমন কিছু নিয়ে চেষ্টা করছিলাম যা আমি ইতিমধ্যে তৈরি করেছি যা সম্ভবত এসওতে রিলে যেতে পারে তার চেয়ে অনেক গভীরতায় যায়। এখানে অন্যান্য সংস্থান যেখানে আমি কাপড় indepth কিছু আবৃত করেছি msdn.microsoft.com/en-us/magazine/jj883952.aspx & msdn.microsoft.com/en-us/magazine/dn342868.aspx & oredev.org / 2013 / বিবাহ-শুক্র-সম্মেলন /…

— জুলি লারম্যান

@JulieLerman এর কোড প্রস্তাবনার সারসংক্ষেপ আমার উত্তর দেখুন stackoverflow.com/a/36789520/1586498

— OzBob

Answer 4

ডিফল্ট স্কিমা সেট করে প্রসঙ্গের পার্থক্য করা

EF6 এ আপনার একাধিক প্রসঙ্গ থাকতে পারে, OnModelCreatingআপনার DbContextউত্পন্ন ক্লাসের পদ্ধতিতে (যেখানে ফ্লুয়েন্ট-এপিআই কনফিগারেশন রয়েছে) ডিফল্ট ডেটাবেস স্কিমার জন্য নাম নির্দিষ্ট করুন । এটি EF6 এ কাজ করবে:

public partial class CustomerModel : DbContext
{   
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("Customer");

        // Fluent API configuration
    }   
}

এই উদাহরণটি আপনার গ্রাহককে আপনার ডাটাবেস সারণির উপসর্গ হিসাবে ব্যবহার করবে ("ডিবিও" এর পরিবর্তে)। আরও গুরুত্বপূর্ণ বিষয় এটি উপসর্গ হবে__MigrationHistory যেমন টেবিলের , যেমন Customer.__MigrationHistory। সুতরাং আপনার কাছে __MigrationHistoryএকটি একক ডাটাবেসে একাধিক টেবিল থাকতে পারে , প্রতিটি প্রসঙ্গে। সুতরাং আপনি একটি প্রসঙ্গে যে পরিবর্তনগুলি করেন তা অন্যের সাথে বিঘ্নিত হবে না।

মাইগ্রেশন যুক্ত করার সময়, কমান্ডের DbMigrationsConfigurationপ্যারামিটার হিসাবে আপনার কনফিগারেশন ক্লাসের (পুরোপুরি প্রাপ্ত ) পুরোপুরি যোগ্যতাসম্পন্ন নামটি উল্লেখ করুন add-migration:

add-migration NAME_OF_MIGRATION -ConfigurationTypeName FULLY_QUALIFIED_NAME_OF_CONFIGURATION_CLASS

প্রসঙ্গ কীতে একটি ছোট শব্দ

এই এমএসডিএন নিবন্ধ অনুসারে " অধ্যায় - একই ডাটাবেসকে লক্ষ্য করে একাধিক মডেলগুলি " ইএফ 6 সম্ভবত একটি মাত্র MigrationHistoryটেবিলের অস্তিত্ব থাকলেও পরিস্থিতি পরিচালনা করতে পারে , কারণ সারণীতে একটি রয়েছে মাইগ্রেশন পার্থক্য করার কনটেক্সটকি কলাম রয়েছে।

তবে আমি MigrationHistoryউপরে বর্ণিত ডিফল্ট স্কিমা উল্লেখ করে একাধিক টেবিল থাকা পছন্দ করি ।

পৃথক স্থানান্তর ফোল্ডার ব্যবহার করা

এ জাতীয় পরিস্থিতিতে আপনি আপনার প্রকল্পের বিভিন্ন "মাইগ্রেশন" ফোল্ডারগুলির সাথেও কাজ করতে চাইতে পারেন। সম্পত্তিটি DbMigrationsConfigurationব্যবহার করে আপনি সেই অনুযায়ী আপনার উত্পন্ন ক্লাসটি সেট করতে পারেন MigrationsDirectory:

internal sealed class ConfigurationA : DbMigrationsConfiguration<ModelA>
{
    public ConfigurationA()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\ModelA";
    }
}

internal sealed class ConfigurationB : DbMigrationsConfiguration<ModelB>
{
    public ConfigurationB()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\ModelB";
    }
}

সারসংক্ষেপ

সব মিলিয়ে, আপনি বলতে পারেন যে সবকিছু পরিষ্কারভাবে পৃথক করা হয়েছে: প্রজেক্টে প্রবাসী ফোল্ডার এবং ডাটাবেসের টেবিলগুলি।

আমি এমন সমাধান বেছে নেব, যদি সত্ত্বার একটি গ্রুপ থাকে যা একটি বড় বিষয়ের অংশ, তবে একে অপরের সাথে সম্পর্কিত নয় (বিদেশী কীগুলির মাধ্যমে)।

সত্তা গোষ্ঠীগুলির একে অপরের কিছু করার না থাকলে আমি তাদের প্রত্যেকের জন্য একটি পৃথক ডাটাবেস তৈরি করেছি এবং বিভিন্ন প্রকল্পে সেগুলি অ্যাক্সেস করব, সম্ভবত প্রতিটি প্রকল্পের একক প্রসঙ্গে।

Comments

যখন আপনার 2 টি সত্ত্বা বিভিন্ন প্রসঙ্গে রয়েছে তা আপডেট করার দরকার আছে তখন আপনি কী করবেন?

— সটনে

আমি একটি নতুন (পরিষেবাদি) শ্রেণি তৈরি করব যা উভয় প্রসঙ্গেই জানে, একটি ভাল নাম এবং এই শ্রেণীর দায়িত্ব সম্পর্কে চিন্তা করে এবং এর একটি পদ্ধতিতে এই আপডেটটি করবে।

— মার্টিন

Answer 5

নীচেরটি অর্জনের সহজ উদাহরণ:

    ApplicationDbContext forumDB = new ApplicationDbContext();
    MonitorDbContext monitor = new MonitorDbContext();

মূল প্রসঙ্গে বৈশিষ্ট্যগুলি কেবল স্কোপ করুন: (ডিবি তৈরি এবং রক্ষণাবেক্ষণের জন্য ব্যবহৃত হয়) দ্রষ্টব্য: কেবল সুরক্ষিত ব্যবহার করুন: (সত্তা এখানে প্রকাশ করা হয়নি)

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("QAForum", throwIfV1Schema: false)
    {

    }
    protected DbSet<Diagnostic> Diagnostics { get; set; }
    public DbSet<Forum> Forums { get; set; }
    public DbSet<Post> Posts { get; set; }
    public DbSet<Thread> Threads { get; set; }
    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
    }
}

মনিটরকন্টেক্সট: পৃথক সত্তা এখানে প্রকাশ করুন

public class MonitorDbContext: DbContext
{
    public MonitorDbContext()
        : base("QAForum")
    {

    }
    public DbSet<Diagnostic> Diagnostics { get; set; }
    // add more here
}

ডায়াগনস্টিক্স মডেল:

public class Diagnostic
{
    [Key]
    public Guid DiagnosticID { get; set; }
    public string ApplicationName { get; set; }
    public DateTime DiagnosticTime { get; set; }
    public string Data { get; set; }
}

আপনি যদি পছন্দ করেন যে আপনি সমস্ত সত্ত্বাকে মূল অ্যাপ্লিকেশনডিবি কনটেক্সট এর ভিতরে সুরক্ষিত হিসাবে চিহ্নিত করতে পারেন, তবে স্কিমার প্রতিটি বিভাজনের জন্য প্রয়োজনীয় প্রাসঙ্গিক তৈরি করুন।

তারা সকলেই একই সংযোগের স্ট্রিং ব্যবহার করে তবে তারা পৃথক সংযোগ ব্যবহার করে, তাই লেনদেনকে অতিক্রম করবেন না এবং লকিংয়ের বিষয়ে সচেতন হন। সাধারণত আপনার নকশাকরণ পৃথকীকরণ যাতে এটি যাইহোক ঘটবে না।

Comments

এটি অনেক সাহায্য করেছিল। "গৌণ" প্রসঙ্গে ভাগ করা সারণী ঘোষণার দরকার নেই। ম্যানুয়ালি এটি DbSet<x>সংজ্ঞা যুক্ত করুন। আমি এটি একটি আংশিক শ্রেণিতে করি যা EF ডিজাইনার যা তৈরি করে তার সাথে মিলে যায়।

— গ্লেন লিটল

আপনি আমাকে অনেক মাথা ব্যাথা বাঁচিয়েছেন, স্যার! আপনি গৃহীত উত্তরের পরিবর্তে একটি শক্ত সমাধান সরবরাহ করেছেন। সত্যিই প্রশংসা!

— ওওআইইইই

Answer 6

অনুস্মারক: আপনি যদি একাধিক প্রসঙ্গে একত্রিত হন তা নিশ্চিত করে নিন যে আপনি আপনার বিভিন্ন RealContexts.OnModelCreating()মধ্যে সমস্ত কার্যকারিতা আপনার একক মধ্যে পেস্ট করেছেন CombinedContext.OnModelCreating()।

আমার ক্যাসকেড মুছে ফেলার সম্পর্কগুলি কেন কেবল modelBuilder.Entity<T>()....WillCascadeOnDelete();আমার সংযুক্ত প্রসঙ্গে আমার আসল প্রসঙ্গ থেকে কোডটি পোর্ট করা হয়নি তা আবিষ্কার করার জন্য আমি কেবল শিকারে সময় নষ্ট করেছিলাম ।

Comments

কাটা এবং পেস্ট করার পরিবর্তে, আপনি কি কেবল OtherContext.OnModelCreating()আপনার সম্মিলিত প্রসঙ্গ থেকে কল করতে পারেন ?

— অ্যালেক্সফক্সগিল

Answer 7

আমি এই নকশাটি জুড়ে এসে আমার অন্ত্রটি আমাকে একই কথা বলেছিল।

আমি এমন একটি কোড বেসে কাজ করছি যেখানে একটি ডাটাবেসে তিনটি ডিবি কনটেক্সট রয়েছে। 3 dbcontexts এর মধ্যে 2 জন 1 dbcontext এর তথ্যের উপর নির্ভরশীল কারণ এটি প্রশাসনিক ডেটা সরবরাহ করে। আপনি কীভাবে আপনার ডেটা জিজ্ঞাসা করতে পারেন তার উপর এই নকশা সীমাবদ্ধতা রেখেছে। আমি এই সমস্যায় পড়েছি যেখানে আপনি dbcontexts জুড়ে যোগ দিতে পারবেন না। পরিবর্তে আপনাকে যা করতে হবে তা হল দুটি পৃথক ডিবিকোনটেক্সটকে কোয়েরি করা, তারপরে স্মৃতিতে একটি যোগদান করুন বা ফলাফল সেট হিসাবে দুটির সংমিশ্রণ পেতে উভয়ের মাধ্যমে পুনরাবৃত্তি করুন। সমস্যাটি হ'ল কোনও নির্দিষ্ট ফলাফলের জন্য জিজ্ঞাসা করার পরিবর্তে আপনি এখন আপনার সমস্ত রেকর্ডকে মেমরিতে লোড করছেন এবং তারপরে স্মৃতিতে দুটি ফলাফলের সেটগুলির বিরুদ্ধে একটি জয়েন করছেন। এটি সত্যই জিনিসকে ধীর করতে পারে।

আমি প্রশ্ন জিজ্ঞাসা "শুধু আপনি করতে পারেন, তাই না?"

এই নকশাটির সাথে সম্পর্কিত সমস্যার জন্য আমি এই নিবন্ধটি দেখুন specified নির্দিষ্ট লিনকিউ এক্সপ্রেশনটিতে বিভিন্ন প্রসঙ্গে প্রাসঙ্গিক প্রশ্নের সাথে উল্লেখ রয়েছে

Comments

আমি একটি বৃহত সিস্টেমে কাজ করেছি যেখানে আমাদের একাধিক প্রসঙ্গ ছিল। আমি যে জিনিসগুলির সন্ধান পেয়েছি তা হ'ল কখনও কখনও আপনাকে একই ডিবিসেটকে একাধিক প্রসঙ্গে অন্তর্ভুক্ত করতে হয়েছিল। একদিকে এটি কিছু খাঁটি উদ্বেগকে ভেঙে দেয় তবে এটি আপনাকে আপনার অনুসন্ধানগুলি সম্পূর্ণ করার অনুমতি দেয়। এমন একটি মামলার জন্য যেখানে আপনার কয়েকটি নির্দিষ্ট অ্যাডমিন টেবিলগুলি পড়ার দরকার রয়েছে, আপনি সেগুলি একটি বেস ডিবি কনটেক্সট ক্লাসে যুক্ত করতে পারেন এবং সেগুলি আপনার অ্যাপ্লিকেশন মডিউল প্রসঙ্গে প্রেরণ করতে পারেন। আপনার "প্রকৃত" অ্যাডমিন প্রসঙ্গের উদ্দেশ্যটিকে সমস্ত অ্যাক্সেস সরবরাহ না করে "অ্যাডমিন টেবিলগুলির রক্ষণাবেক্ষণ সরবরাহ" হিসাবে পুনরায় সংজ্ঞায়িত করা যেতে পারে।

— জেমার্চ

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

— জেমার্চ

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

— ব্যবহারকারী 1496062

Answer 8

[@ জুলিমারম্যানের ডিডিডি এমএসডিএন ম্যাগ আর্টিকেল 2013] দ্বারা অনুপ্রাণিত [1]

    public class ShippingContext : BaseContext<ShippingContext>
{
  public DbSet<Shipment> Shipments { get; set; }
  public DbSet<Shipper> Shippers { get; set; }
  public DbSet<OrderShippingDetail> Order { get; set; } //Orders table
  public DbSet<ItemToBeShipped> ItemsToBeShipped { get; set; }
  protected override void OnModelCreating(DbModelBuilder modelBuilder)
  {
    modelBuilder.Ignore<LineItem>();
    modelBuilder.Ignore<Order>();
    modelBuilder.Configurations.Add(new ShippingAddressMap());
  }
}

---

public class BaseContext<TContext>
  DbContext where TContext : DbContext
{
  static BaseContext()
  {
    Database.SetInitializer<TContext>(null);
  }
  protected BaseContext() : base("DPSalesDatabase")
  {}
}   

"আপনি যদি নতুন উন্নয়ন করছেন এবং আপনি কোডটি প্রথম আপনার ক্লাসের উপর ভিত্তি করে আপনার ডাটাবেস তৈরি বা স্থানান্তর করতে দিতে চান, আপনাকে একটি ডিবি কনটেক্সট ব্যবহার করে একটি" উবার-মডেল "তৈরি করতে হবে যার মধ্যে প্রয়োজনীয় সমস্ত শ্রেণি এবং সম্পর্ক রয়েছে includes একটি সম্পূর্ণ মডেল তৈরি করুন যা ডেটাবেসকে উপস্থাপন করে, জেএল

Answer 9

কোডে প্রথমে আপনার একাধিক ডিবিসিওন্টেক্সট এবং কেবল একটি ডাটাবেস থাকতে পারে। আপনাকে কেবল কনস্ট্রাক্টরে সংযোগের স্ট্রিং নির্দিষ্ট করতে হবে।

public class MovieDBContext : DbContext
{
    public MovieDBContext()
        : base("DefaultConnection")
    {

    }
    public DbSet<Movie> Movies { get; set; }
}

Comments

হ্যাঁ আপনি পারেন তবে আপনি বিভিন্ন ডিবি প্রসঙ্গে বিভিন্ন সত্তা থেকে কীভাবে জিজ্ঞাসা করতে পারেন?

— রেজা

Answer 10

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

Answer 11

আমি একটি কেস শেয়ার করতে চাই, যেখানে আমি মনে করি যে একই ডাটাবেসে একাধিক ডিবিসিওন্টেক্সট থাকার সম্ভাবনা ভালভাবে বোঝায়।

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

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

Comments

আমি আমার উত্তরে কোন প্রশ্ন দেখতে ব্যর্থ। আমি একটাই প্রশ্ন করছি না! বরং এমন একটি দৃশ্যের ভাগ করে নেওয়া যেখানে আলোচনার বিষয়টি যথার্থ বোঝায়।

— freilebt

Answer 12

হু, প্রতিটি ডিবি স্কিমার জন্য পৃথক ডিবি প্রসঙ্গে সমস্যা নিয়ে বেশ কিছুটা সময় ব্যয় করেছেন, আশা করি এটি অন্য কাউকে সহায়তা করবে ...

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

এই বিষয়গুলি সি # তে পৃথকভাবে লোড করা হয়েছিল, প্রথমত, 1 প্রসঙ্গ থেকে বিষয়টি লোড করা হয়েছিল, তারপরে ব্যবহারকারীদের অন্য ডিবি প্রসঙ্গ থেকে ব্যবহারকারী আইডির মাধ্যমে লোড করা হয়েছিল - এটি দুর্দান্ত নয়, এটি ঠিক করতে হবে! ( EF 6 সহ একই ডাটাবেসে একাধিক dbcontexts ব্যবহার করার মতো )

প্রথমে, আমি কেবি ডিবি প্রসঙ্গে ইফ মডেলবিল্ডারের সাথে পরিচয় স্কিমা থেকে কেবি স্কিমাতে এফকে নির্দেশাবলী হারিয়ে যাওয়ার চেষ্টা করেছি। একই হিসাবে যদি কেবল 1 টি প্রসঙ্গ থাকে তবে আমি এটি 2 এ পৃথক করে।

modelBuilder.Entity<Topic>(entity =>
{
  entity.HasOne(d => d.Creator)
    .WithMany(p => p.TopicCreator)
    .HasForeignKey(d => d.CreatorId)
    .HasConstraintName("fk_topic_app_users");

এটি কাজ করে না, কারণ কেবি ডিবি প্রসঙ্গে ব্যবহারকারী অবজেক্ট সম্পর্কে কোনও তথ্য ছিল না, পোস্টগ্রাস ত্রুটি ফিরে পেয়েছিল relation "AppUsers" does not exist। বিবৃতি নির্বাচন করুন স্কিমা, ক্ষেত্রের নাম ইত্যাদি সম্পর্কে সঠিক তথ্য নেই।

আমি প্রায় ছেড়ে দিয়েছি, কিন্তু তখন আমি দৌড়ানোর সময় একটি সুইচ "-d" লক্ষ্য করেছি dotnet ef dbcontext scaffold। এটির জন্য ডেটা-টীকাগুলির সংক্ষিপ্ত - মডেলটি (যেখানে সম্ভব) কনফিগার করতে বৈশিষ্ট্যগুলি ব্যবহার করুন। বাদ দেওয়া থাকলে কেবল সাবলীল এপিআই ব্যবহৃত হয়। এই স্যুইচটি নির্দিষ্ট করে দিয়ে, অবজেক্টের বৈশিষ্ট্যগুলি ডিবি প্রসঙ্গে OnModelCreating()নয় বরং অবজেক্টের মধ্যেই গুণাবলী সহ সংজ্ঞায়িত করা হয়েছিল ।

এইভাবে, EF সঠিক ক্ষেত্রের নাম এবং স্কিমার সাথে সঠিক এসকিউএল বিবৃতি উত্পন্ন করার জন্য পর্যাপ্ত তথ্য পেয়েছে।

টিএল; ডিআর: পৃথক ডিবি প্রসঙ্গে তাদের মধ্যে সম্পর্কগুলি (এফকে) ভালভাবে পরিচালনা করে না, প্রতিটি প্রসঙ্গে কেবলমাত্র নিজস্ব সত্তা সম্পর্কে তথ্য রয়েছে has "-ডাটা-টীকাগুলি" স্যুইচ চালু করার সময় dotnet ef dbcontext scaffold, এই তথ্যগুলি প্রতিটি পৃথক প্রসঙ্গে সংরক্ষণ করা হয় না, তবে ডিবি অবজেক্টগুলিতে থাকে।