কোনও ওআরএম ব্যবহার না করার জন্য কি কোনও ভাল কারণ রয়েছে? [বন্ধ]


107

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

তবে, এনএইচবারনেট বা অনুরূপ প্রকল্প না ব্যবহারের মূল দুটি কারণ আমি পুরোপুরি বুঝতে পারি না:

  1. কেউ কেবল এসকিউএল কোয়েরি দিয়ে নিজের ডেটা অ্যাক্সেসের অবজেক্ট তৈরি করতে পারে এবং মাইক্রোসফ্ট এসকিউএল সার্ভার ম্যানেজমেন্ট স্টুডিওর বাইরে এই প্রশ্নাগুলি অনুলিপি করতে পারে।
  2. একটি ORM ডিবাগ করা কঠিন হতে পারে।

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

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

পরিশেষে, উপরে বর্ণিত argu যুক্তিগুলি কি একটি তুচ্ছ-ডাটাবেস ভিত্তিক এন্টারপ্রাইজ অ্যাপ্লিকেশনটির জন্য কোনও ওআরএম ব্যবহার না করার জন্য একটি ভাল কারণ? তারা / আমি সম্ভবত মিস করেছি কি অন্য যুক্তি আছে?

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

উত্তর:


26

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

কেন একটি ORM জিনিসগুলি ডিবাগ করা কঠিন করে তুলবে? এটি কোনও সঞ্চিত প্রকোপ থেকে বা ওআরএম থেকে আসে না কেন আপনি একই ফল পাবেন।

আমি অনুমান করি যে কোনও ওআরএম দিয়ে আমি যে আসল ক্ষয়ক্ষতি ভাবতে পারি তা হ'ল সুরক্ষা মডেলটি একটু কম নমনীয়।

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


1
ডিবাগ করা আরও কঠিন: যদি কোনও ব্যতিক্রম ছুঁড়ে দেওয়া হয় তবে আপনার সম্ভবত স্ক্যাল সংযোগের ব্যতিক্রমগুলি ইত্যাদি জানার পরিবর্তে কাঠামোটি জানা দরকার
হ্যাঙ্গ

4
স্কয়ার ব্যতিক্রম কি ওআরএম ব্যতিক্রমের অংশ হবে না?
জিওভান্নি গাল্বো

1
হ্যাঁ, বেশিরভাগ ব্যতিক্রমটি মুড়ে রাখুন, সুতরাং আপনি এখনও মূল ব্যতিক্রমটি পেতে সক্ষম হবেন। ইনার
ম্যাটল্যান্ট

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

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

58

সংক্ষিপ্ত উত্তর হ্যাঁ, সত্যিই ভাল কারণ আছে। প্রকৃতপক্ষে এমন কিছু মামলা রয়েছে যেখানে আপনি কেবল একটি ওআরএম ব্যবহার করতে পারবেন না।

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


25
আমি মনে করি এটি বর্তমান orm গ্রন্থাগারগুলির সীমাবদ্ধতা যা ম্যাপিং বা ম্যাপিংয়ের ক্ষেত্রে মৌলিক সীমাবদ্ধতার চেয়ে সঞ্চিত প্রক্রিয়াটিকে সমর্থন করে না। এমন কিছু আছে যা সংরক্ষণাগারভিত্তিক প্রকল্পগুলি এবং দর্শনগুলি পরিচালনা করতে পারে এবং orm + সঞ্চিত প্রকল্পগুলির সমাধানের জন্য অনেক কিছুই বলা যায়।
মেন্ডল্ট

4
একটি ভাল ওআরএমের ক্ষেত্রে, আপনি যেভাবেই এসপি ব্যবহার করতে সক্ষম হবেন (অবশ্যই, এটি অনেক উপকারগুলি হ্রাস করে ...)
k

3
কোনও ওআরএম ভাল জমিদার ক্ষেত্রের চেয়ে এসপিরা কেন সত্যিই বেশি সুরক্ষা দেয় না সে বিষয়টি The এখানে কেবল একটি নিবন্ধ যা এটিকে ভালভাবে সম্বোধন করে: ayende.com/Blog/archive/2007/11/18/…
টিম স্কট

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

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

55

ওআরএমের মিষ্টি স্পট

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

আপনার হাতে বেশ কয়েকটি মুশকিল থাকতে পারে যা হাত দিয়ে আরও ভাল করা হয়। এই ক্ষেত্রে, এটি পরিচালনা করতে কয়েকটি সঞ্চিত পদ্ধতি লিখতে ভয় করবেন না। এমনকি আপনি যদি একাধিক ডিবিএমএস প্ল্যাটফর্ম জুড়ে আপনার অ্যাপ্লিকেশনটি পোর্ট করতে চান তবে ডাটাবেস নির্ভর কোডটি সংখ্যালঘুতে থাকবে। আপনি যে প্ল্যাটফর্মে এটি সমর্থন করার ইচ্ছা নিয়েছেন তার আবেদন পরীক্ষা করার দরকার মনে রাখবেন, কিছু সঞ্চিত পদ্ধতির জন্য অতিরিক্ত কিছু পোর্টিং প্রচেষ্টা আপনার টিসিওর সাথে খুব বেশি পার্থক্য আনবে না। প্রথম অনুমানের জন্য, 98% পোর্টেবল কেবল 100% পোর্টেবলের মতোই ভাল, এবং কোনও ওআরএম এর সীমাবদ্ধতার আশপাশে কাজ করার জন্য সংশ্লেষিত বা দুর্বল সম্পাদনের সমাধানের চেয়ে অনেক ভাল।

আমি প্রাক্তন পদ্ধতির খুব বড় (100-এর কর্মী-বছরের) J2EE প্রকল্পে ভাল কাজ করতে দেখেছি।

যেখানে কোনও ওআরএম সেরা ফিট নাও হতে পারে

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

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

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

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

  • উচ্চ-সম্পাদনা অ্যাপ্লিকেশনগুলি যেখানে আপনি আপনার ডেটাবেস অ্যাক্সেসকে সত্যি টিউন করতে চান want এই ক্ষেত্রে, নিম্ন স্তরে কাজ করা ভাল।

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

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


"বা অন্যান্য ধরণের সিস্টেমে যেখানে ডেটা অখণ্ডতা গুরুত্বপূর্ণ" ... সামাজিক ওয়েবসাইটগুলি বাদ দিয়ে যদি আপনার ডেটার অখণ্ডতা গুরুত্বপূর্ণ না হয় তবে কেন একটি সিস্টেমকে বিল্ডিং করতে মোটেই বিরক্ত করবেন?
ওবিওয়ানকেনোবি

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

1
আমি জানি এটি এক বছর কেটে গেছে, তবে আপনার কাছে +1 তথ্যটি উল্লেখ করার জন্য যে কখনও কখনও ডেটা কেবল কেবল এটিই হয় ডেটা।
luis.espinal

37

প্রথমত - একটি ওআরএম ব্যবহার করা আপনার কোডটিকে পরীক্ষা করা সহজতর করে না, বা এটি অবিচ্ছিন্নভাবে সংহত দৃশ্যে কোনও সুবিধা প্রদান করবে না।

আমার অভিজ্ঞতায়, যখন একটি ওআরএম ব্যবহার করা উন্নয়নের গতি বাড়িয়ে তুলতে পারে, আপনাকে সবচেয়ে বড় সমস্যাগুলির সমাধান করতে হবে:

  1. আপনার কোড পরীক্ষা করা হচ্ছে
  2. আপনার কোড বজায় রাখা

এর সমাধানগুলি হ'ল:

  1. আপনার কোডটিকে পরীক্ষণযোগ্য করে তোলেন ( সোলিড নীতি ব্যবহার করে)
  2. যতটা সম্ভব কোডের জন্য স্বয়ংক্রিয় পরীক্ষাগুলি লিখুন
  3. যতবার সম্ভব স্বয়ংক্রিয় পরীক্ষা চালানো

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

নিজের হাতে SELECT কোয়েরি লিখতে না পারার (যা আমার ধারণা, কপি-পেস্টের প্রয়োজন কেন) মনে হয় যে কিছু এসকিউএল প্রশিক্ষণের জরুরি প্রয়োজন আছে।

আমি কোনও ওআরএম ব্যবহার না করার দুটি কারণ রয়েছে:

  1. এটি কোম্পানির নীতি দ্বারা কঠোরভাবে নিষিদ্ধ (এই ক্ষেত্রে আমি অন্য কোথাও কাজ করতে যাব)
  2. প্রকল্পটি অত্যন্ত ডেটা নিবিড় এবং বিক্রেতার নির্দিষ্ট সমাধানগুলি (বल्कআইন্ট্রের মতো) ব্যবহার করে আরও বোঝা যায়।

ওআরএম (বিশেষত এনএইচবারনেট) সম্পর্কিত সাধারণ ত্রুটিগুলি হ'ল:

  1. গতি

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

  2. জটিলতা

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

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

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

(কীভাবে বাচ্চাদের জন্য?)


33

প্রচুর সাধারণ সমস্যা রয়েছে যার জন্য হাইবারনেটের মতো ওআরএম সরঞ্জামগুলি godশ্বরের পাঠানো, এবং কয়েকটি যেখানে এটি বাধা। আপনার প্রকল্পটি কোনটি তা জানার জন্য আমি পর্যাপ্ত পরিমাণে জানি না।

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

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

সম্পাদনা: আপনি যদি আইবিটিস.এনইটি NHibernate সম্পর্কে ঘুরিয়ে না ফেরাচ্ছেন এবং তারা তাদের এসকিউএল অনুসন্ধানগুলির উপর নিয়ন্ত্রণ চান তবে আপনি তাদের অনুসন্ধান করতে চাইতে পারেন।

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


3
পুনরাবৃত্তি আর সত্য নয়। আপনি যদি জেপিএ টিকা ব্যবহার করেন তবে আপনার একবারে জিনিস নির্দিষ্ট করতে হবে। হাইবারনেট এমনকি আপনার ডাটাবেসটি আপনার জন্য বিবৃতি তৈরি করবে, যদিও এটি আপনার ম্যাপিংটি সঠিক ছিল কিনা তা নির্ধারণের জন্য সবচেয়ে কার্যকর।
জোনাথন-স্টাফর্ড

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

2
8 বছর কেটে গেছে, তবে এটি এখনও সত্য: "আপনি যখন জানেন যে আপনি কয়েক মিনিটের মধ্যে এসকিউএল স্থির করতে পারতেন তবে এটি খুব বিরক্তিকর হতে পারে, তবে পরিবর্তে আপনি আপনার ডাঙার সরঞ্জামটি যুক্তিযুক্ত এসকিউএল তৈরির জন্য কয়েক ঘন্টা ব্যয় করছেন" "
রুসলান স্টেলমাচেঙ্কো

13

আমি এমন একটি প্রকল্পে কাজ করেছি যেখানে কোনও ওআরএম ব্যবহার করা খুব সফলভাবে হয়নি। এটি একটি প্রকল্প ছিল

  1. শুরু থেকেই অনুভূমিকভাবে স্কেলালবে হতে হয়েছিল
  2. দ্রুত বিকাশ করতে হবে
  3. তুলনামূলকভাবে সহজ ডোমেন মডেল ছিল

অনুভূমিকভাবে বিভাজনযুক্ত কাঠামোয় এনহাইবারনেটকে কাজ করতে যে সময়টি গ্রহণ করা উচিত ছিল তা আমাদের পার্টিশন স্কিম সম্পর্কে সচেতন এমন একটি অতি সাধারণ ডেটাম্পার বিকাশ করতে যে সময়ের চেয়ে বেশি সময় পারত ...

সুতরাং, আমি একটি ওআরএম-তে কাজ করেছি এমন 90% প্রকল্পের একটি অমূল্য সহায়তা হয়েছে। তবে কিছু খুব নির্দিষ্ট পরিস্থিতি রয়েছে যেখানে আমি দেখতে পাচ্ছি যে কোনও ওআরএমকে সর্বোত্তম হিসাবে ব্যবহার করা হচ্ছে না।


আপনি নির্দিষ্ট কিছু ক্ষেত্রে একটি ওআরএম ব্যবহারের বিরুদ্ধে কিছু ভাল পয়েন্ট দিয়েছেন। যাইহোক, এই প্রকল্পটি সেই 90% এর অন্তর্গত যেখানে ওআরএম সম্ভবত উন্নয়ন এবং রক্ষণাবেক্ষণের ব্যয় হ্রাস করতে সহায়তা করতে পারে।
হ্যাঙ্গ

সম্পূর্ণ সম্মত - আপনার প্রশ্নের সরাসরি উত্তর না দেওয়ার জন্য দুঃখিত! আমি বিশ্বাস করি যে আপনি নির্দিষ্ট কারণগুলি উল্লেখ করেছেন তা বেশিরভাগ অবৈধ :)
মাইক

অনুভূমিকভাবে স্কেলিং NHibernate: blechie.com/WPierce/archive/2008/06/08/… , darioquintana.com.ar/blogging/?p=25
মরিসিও শেফার

11

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

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

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


9

আপনার 50000000 রেকর্ড আপডেট করার দরকার হলে। একটি পতাকা নির্ধারণ করুন বা যাই হোক না কেন।

কোনও স্টোরেজ পদ্ধতি বা নেটিভ এসকিউএল কমান্ডগুলি কল না করেই একটি ORM ব্যবহার করে এটি করার চেষ্টা করুন ..

আপডেট 1: এর কয়েকটি ক্ষেত্রের সাথে একটি রেকর্ড পুনরুদ্ধার করার চেষ্টা করুন। (যখন আপনার খুব "প্রশস্ত" টেবিল থাকে)। বা একটি স্কেলার ফলাফল ওআরএমগুলিও এটি স্তন্যপান করে।

আপডেট 2 : দেখে মনে হচ্ছে যে EF 5.0 বিটা ব্যাচের আপডেটের প্রতিশ্রুতি দিলেও এটি খুব হট নিউজ (২০১২, জানুয়ারী)



9

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

বৈশিষ্ট্যগুলি একদিকে:

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

যুক্তিটিতে কিছুটা দৃষ্টিভঙ্গি রাখতে, ADO.NET বনাম বনাম কোডটি টেবুলার ডেটা স্ট্রিমটি বিশ্লেষণ করার জন্য কোডটি লেখার সুবিধাগুলি বিবেচনা করুন।

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

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

আপনার সিনিয়র দলের সদস্যদের অভিজ্ঞতা আপনাকে কম্পিউটার বিজ্ঞানের বিবর্তনের বিপরীত দিকে টেনে আনতে দেবেন না। আমি ২৩ বছর ধরে পেশাগতভাবে বিকাশ করছি এবং ধ্রুবকগুলির মধ্যে একটি হ'ল পুরাতন-স্কুলটি নতুনের প্রতি অপছন্দ। OR ভাষাগুলি এসকিউএল-তে যেমন সি ভাষাটি অ্যাসেমব্লিতে ছিল, এবং আপনি বাজি ধরতে পারেন যে সি ++ এবং সি # এর সমতুল্য তাদের পথে চলেছে। নতুন স্কুল কোডের একটি লাইন পুরানো-স্কুলের 20 লাইনের সমান।


8

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

আমি মনে করি এটি পুরো ডেটা অ্যাক্সেস লেয়ারকে কোডিংয়ের মধ্যে মাঝখানে এবং একটি ওআরএম ব্যবহার করবে ...


6

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

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

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

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


5

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


আপনি কি এ ব্যাপারে নিশ্চিত? ওএলপিগুলি ওআরএম-এর সাথে যেমন ওএলএপগুলি উপযুক্ত ততটুকু অনুপযুক্ত (যার অর্থ, জটিলতার উপর নির্ভর করে)। এই দুটি চরমের মধ্যে একটি বিস্তৃত অ্যাপ্লিকেশন রয়েছে যার জন্য একটি ওআরএম একটি ভাল কাজ করে। তবে ওএলএপি এবং ওএলটিপিগুলির জন্য, তারা বাধা হয়ে উঠতে পারে।
luis.espinal

4

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

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

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

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

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


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

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

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

3

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

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


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

3

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

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

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


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

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

1
এটি একটি সতর্কতা ... একটি বিবৃতি ব্যবহার করবেন না। এবং এটি তিনটি সমস্যার মধ্যে একটি মাত্র সতর্কতা।
ড্যাক্রাকট

1
@ ড্যাক্রাকোট: আপনি সর্বদা প্রচুর বিদেশী কোডের উপর নির্ভর করছেন ... আপনার অপারেটিং সিস্টেম থেকে শুরু করে, তাই আমি মনে করি না যে আপনার বিন্দুটি একটি বৈধ কোড। আশাবাদী লকিং ব্যবহার করে দ্বিতীয় পয়েন্টটি প্রশমিত করা যায়, তদুপরি দ্বি-পর্বের অঙ্গীকারের সাথে এর তেমন কিছু করার নেই।
অ্যাডাম বাইরটেক

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

3

আমি ওআরএম এর ডাউনসাইডগুলির তালিকার জন্য এই পড়ার পরামর্শ দিই।

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

আমার নিজের জন্য, আমি লিখেছি বেশিরভাগ অ্যাপ্লিকেশনগুলির জন্য আমি ORM গুলি খুব দরকারী বলে খুঁজে পেয়েছি!

/ Asger


3

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

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

ওআরএম ব্যবহার করতে, এটি সত্যই বুঝতে হবে। দুর্ভাগ্যক্রমে একজন সহজেই এমন ধারণা তৈরি করে যে এটি সহজ নয় while


হাইবারনেট ইউনিয়ন সমর্থন করে না? সেট সেট তত্ত্বের একটি সুন্দর মৌলিক অংশ! আমি মনে করি এটি সমস্যা সম্পর্কে চিন্তা করার জন্য অন্য কোনও উপায় নির্দেশ করে।
টম

3

প্রতি সেউ উত্তর হবে না, আমি সম্প্রতি শুনেছি একটি উদ্ধৃতি পুনরায় লিখতে চাই। "একটি ভাল ওআরএম হ'ল ইয়েতির মতো, প্রত্যেকে একজনের কথা বলে তবে কেউ তা দেখে না।"

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

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


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

2

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

প্রশ্নগুলির অনুলিপি এবং আটকানো এবং পাঠ্যে হার্ডকোডিং কোনও নমনীয়তা দেয় না কারণ # 1 এর পক্ষে কোনও যুক্তি নেই, এবং # 2 এর জন্য বেশিরভাগ orm এর মূল ব্যতিক্রমটি গুটিয়ে ফেলতে পারে, উত্পন্ন অনুসন্ধানগুলি ইত্যাদির সন্ধান করবে ইত্যাদি, সুতরাং রকেট বিজ্ঞানের ডিবাগিংও নয়।

বৈধতা হিসাবে, একটি ওআরএম ব্যবহার সাধারণত বৈধতা তৈরির উপরে, বৈধতা কৌশলগুলি বিকাশের জন্য আরও সহজ সময়কে মঞ্জুরি দেয়।

আপনার নিজস্ব কাঠামো লেখা শ্রমসাধ্য হতে পারে এবং প্রায়শই জিনিসগুলি মিস হয়ে যায়।

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


1

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

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

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

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

অন্যথায়, ওআরএম সহ জাহান্নামে। আমি এখন এগুলিকে মূলত ফ্যাড হিসাবে বিবেচনা করি।

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