আপনার নিজের ডেটা অ্যাক্সেস / ডেটা ম্যাপিং লেয়ারটি কি "ভাল" ধারণাটি লিখছেন?


20

আমরা বর্তমানে এমন পরিস্থিতিতে আছি যেখানে বাক্সের বাইরে থাকা অবজেক্ট-রিলেশনাল ম্যাপার ব্যবহার বা আমাদের নিজস্ব ঘূর্ণনের মধ্যে আমাদের একটি পছন্দ আছে

আমাদের একটি লিগ্যাসি অ্যাপ্লিকেশন রয়েছে (এএসপি.নেট + এসকিউএল সার্ভার) যেখানে দুর্ভাগ্যক্রমে ডেটা স্তর এবং ব্যবসায়-স্তর একসাথে ছাঁটাই হয়েছে। ডেটা অ্যাক্সেসের ক্ষেত্রে সিস্টেমটি বিশেষভাবে জটিল নয়। এটি আন্তঃসম্পর্কিত টেবিলগুলির বৃহত গোষ্ঠী (35-40) থেকে ডেটা পড়ে, মেমরিতে এটিকে পরিচালনা করে এবং সংক্ষিপ্ত বিন্যাসে এটিকে আবার কিছু টেবিলগুলিতে সংরক্ষণ করে sa আমাদের কাছে এখন কিছু রিফ্যাক্টরিংয়ের সুযোগ রয়েছে এবং আমাদের ডেটা অ্যাক্সেসকে আলাদা এবং সঠিকভাবে কাঠামোগত করার জন্য প্রার্থী প্রযুক্তিগুলির দিকে নজর রাখছি।

আমরা যে প্রযুক্তি সম্পর্কে সিদ্ধান্ত নিই তা আমাদের করতে চাই:

  • আমাদের ডোমেন মডেলটিতে পোকো অবজেক্ট রয়েছে যা দৃistence়তা উপেক্ষা করে
  • একটি বিদ্রূপহীন অন্তর্নিহিত ডেটাসোর্সের বিরুদ্ধে আমাদের ডোমেন মডেল অবজেক্টগুলিকে ইউনিট পরীক্ষার অনুমতি দেওয়ার জন্য একটি বিমূর্ততা স্তর রয়েছে

ইতিমধ্যে প্যাটার্নস এবং ফ্রেমওয়ার্ক ইত্যাদির ক্ষেত্রে এটিতে প্রচুর স্টাফ রয়েছে out

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

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

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

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


4
কিছু ভাল আছে (ভাল, যদি আপনি আমাকে জিজ্ঞাসা করেন তবে আমি এই পবিত্র যুদ্ধ শুরু করব না ... ওহ অপেক্ষা করুন) EF এর বিকল্পগুলি যেখানে আপনি এনএইবারবারেটের মতো "কোডটি নিয়ন্ত্রণ করতে" সক্ষম হবেন।
ব্রুক

@ ব্রুক কীভাবে এই ঠিকানাটির প্রশ্নটিকে কীভাবে আপনার নিজের ডেটা অ্যাক্সেস / ডেটা ম্যাপিং লেয়ারটিকে একটি "ভাল" ধারণাটি লিখছেন?
মিকিডি

উত্তর:


22

বিদ্যমান ওআরএম এর বিরুদ্ধে উভয় যুক্তিই অবৈধ:

"আচ্ছা অন্তত আমরা আমাদের নিজস্ব কোডের নিয়ন্ত্রণে থাকব"

কেন নিজের ভাষা লিখবেন না? আপনার নিজস্ব কাঠামো? আপনার নিজের অপারেটিং সিস্টেম? এবং আপনি যে সমস্ত কিছুর নিয়ন্ত্রণে রয়েছেন তা নিশ্চিত হতে আপনার নিজের হার্ডওয়্যারটি তৈরি করাও একটি ভাল ধারণা।

"ওহ আমি আগের প্রকল্পে এল 2 এস / ইএফ ব্যবহার করেছি এবং এটি মাথা ব্যথা ছাড়া কিছুই ছিল না"

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


তো, আপনার নিজের ওআরএম লিখতে হবে?

আমি এটা পরামর্শ দেব না। ইতিমধ্যে পেশাদার-স্তরের ওআরএম রয়েছে, এর অর্থ হল আপনার নিজের লিখতে হবে কেবল যদি:

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

অবশ্যই, কিছুই শিখতে কৌতূহল ছাড়াই আপনার নিজের ORM লিখতে বাধা দেয় না। তবে আপনার এটি কোনও বাণিজ্যিক প্রকল্পে করা উচিত নয়।


চক্রটি পুনর্বহাল করা এবং এটির জন্য আফসোস না করা প্রশ্নের আমার উত্তরটির 2 থেকে 3 পয়েন্টও দেখুন । আপনি দেখতে পারেন যে চক্রটি পুনর্নির্মাণের বিভিন্ন কারণগুলি এখানে প্রয়োগ হয় না।


10
1. সিস্টেমের ব্যবসায়ের সমালোচনামূলক অংশগুলির নিয়ন্ত্রণে থাকা প্রায়শই একটি ভাল ধারণা। কখনও কখনও এটি কোনও প্রতিষ্ঠিত এবং জনপ্রিয় গ্রন্থাগার ব্যবহার না করে নিজের কাঠামো লিখতে পারে। 2. কখনও কখনও জনপ্রিয় সরঞ্জামগুলি ওভারসোল্ড বা অতিরিক্ত চাপ দেওয়া হয়।
কোয়ান্ট_দেব

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

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

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

2
কেন নিজের ভাষা লিখবেন না? আপনার নিজস্ব কাঠামো? আপনার নিজের অপারেটিং সিস্টেম? এবং আপনি যে সমস্ত কিছুর নিয়ন্ত্রণে রয়েছেন তা নিশ্চিত হওয়ার জন্য, আপনার নিজের হার্ডওয়্যার তৈরি করাও একটি ভাল ধারণা যা অ্যাপল বলেছিল :-)
কোনামিমন

19

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


তার জন্য চিয়ার্স হ্যাঁ সেখানেই আমি এটি ধাক্কা দেওয়ার চেষ্টা করছি।
ইইন ক্যাম্পবেল

বিশেষত যেহেতু EF প্রযুক্তি এম is তে চলেছে। এবং লিনক দেব জীবনকে এত সহজ করে তোলে।
SoylentGray

স্ট্যাকওভারফ্লো যে বেশিরভাগ রাস্তায় নেমে গেছে, সফলভাবে তাই না? সমস্ত সাধারণ স্টাফের জন্য লিনক-টু-এসকিউএল, এবং প্রয়োজনীয় বিটগুলির জন্য ড্যাপার লাইব্রেরিতে রূপান্তরিত কাস্টম স্টাফ।
কারসন 63000

5

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

বটম লাইন যে এটা করতে অর্থে দেখা যায় শুধুমাত্র সঠিক অবস্থার অধীনে। এই শর্তগুলির মধ্যে সাধারণত অন্তর্ভুক্ত থাকে:

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

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

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

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

  1. যে বিন্দুতে পয়েন্টটি সঠিক বলে মনে হয়, যথাযথভাবে সত্য দ্বারা সমর্থিত ইত্যাদি, এবং
  2. যে প্রকল্পটিতে পয়েন্টটি হাতের প্রকল্পে প্রয়োগ করা হবে বলে মনে হচ্ছে।

তারপরে আমি সিদ্ধান্ত নিয়ে আসা কাগজপত্রগুলি এবং সমালোচনাগুলি মূল্যায়ন করব (যদিও পুরোপুরি সৎ, তবে সিদ্ধান্ত নেওয়াতে আমি তাদের কতটা ব্যবহার করেছিলাম, এবং সিদ্ধান্তকে ন্যায়সঙ্গত করতে আমি তাদের কতটা ব্যবহার করেছিলাম তা বলা মুশকিল হতে পারে) আমি ইতিমধ্যে তৈরি করেছি - আমি জানি আমার সম্ভবত এটি স্বীকার করা উচিত নয়, তবে বাস্তবতা হ'ল আমিও মানুষ ...)

সম্পাদনা:

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

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

  1. সবকিছু ঠিকঠাক চললে এটি করা সম্ভবের সেরাতম কেসের অনুমান esti
  2. "স্বাভাবিক" অনুমান - আপনি এটি কতক্ষণ নিবেন বলে আশা করেন।
  3. যদি সব কিছু ভুল হয়ে যায় তবে এটি সবচেয়ে দীর্ঘস্থায়ী পরিস্থিতিটির অনুমান could

অবশ্যই, সর্বোত্তম- এবং সবচেয়ে খারাপ ক্ষেত্রে অনুমানগুলি সাধারণত সরাসরি divineশিক হস্তক্ষেপের মতো জিনিসগুলি অন্তর্ভুক্ত করা উচিত নয়, তবে এর থেকে সংক্ষিপ্ত কিছু অন্তর্ভুক্ত করা উচিত।


জেরির জন্য ধন্যবাদ। (এই উত্তরের আরও উন্নতি প্রয়োজন :-))
ইয়োন ক্যাম্পবেল ২

@ ব্যয় সম্পর্কে জেরি চমৎকার পয়েন্টটি, শেষ অবধি ম্যানেজমেন্ট কী বিষয়ে যত্নশীল তা তবে আপনার "শিক্ষাগত" অনুরোধে আপনাকে কিছুটা ঝুঁকি অন্তর্ভুক্ত করতে হবে। কোনও প্রকল্পে যুক্ত ঝুঁকির প্রশংসা করতে ব্যর্থতা হ'ল সাধারণত সর্বনিম্ন বিড প্রকল্পগুলিকে অন্যান্য বিকল্পের চেয়ে ব্যয়বহুল করে তোলে।
সিডিএমএনকি

@ সিডিএমএনকি: ভালো কথা। যথাযথভাবে সম্পাদনা করা হচ্ছে।
জেরি কফিন

3

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

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


3

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

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


1

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


0

আমি বলব আপনার নিজের ওআরএম রোল করা একটি বাজে ধারণা - যদি না আপনার কাছে খুব ,শ্বরের কারণ থাকে তবে (বিটিডাব্লু। আপনি যেগুলি উদ্ধৃত করেছেন তা যথেষ্ট ভাল নয় :)

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

নতুন মতিন sems প্রশংসনীয় ভাল হতে, কিন্তু আপনি আরও নিয়ন্ত্রণ চান তাহলে - আমি মাইক্রো ORM এ alook আছে চাই / মত S: Drapper http://code.google.com/p/dapper-dot-net/ বা PetaPOCO HTTP : //www.toptensoftware.com/petapoco/

আপনি মিশ্রণ এবং মিলও করতে পারেন - বেশিরভাগ স্টাফের জন্য EF এবং কিছু সূক্ষ্ম সুরের জন্য ড্রাগার ব্যবহার করুন।

যাইহোক এটি কেবল আমার 2 সি;)

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