কেন আমাদের সত্তা অবজেক্টগুলির প্রয়োজন? [বন্ধ]


139

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

আমি বিশ্বাস করি না যে সত্তা অবজেক্টের উপস্থিতি হওয়া উচিত।

সত্তা অবজেক্টের দ্বারা আমি আমাদের অ্যাপ্লিকেশনগুলির জন্য যেমন সাধারণ জিনিসগুলি তৈরি করতে চাই তা বোঝায়, যেমন "ব্যক্তি", "অ্যাকাউন্ট", "আদেশ", ইত্যাদি for

আমার বর্তমান নকশা দর্শন এটি:

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

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

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

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

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

আমি যুদ্ধের পরীক্ষিত উপসংহার এসেছেন যে সত্তা বস্তু আমাদের পথ পেয়ে হয়, এবং আমাদের জীবনে হবে তাই অনেক তাদের ছাড়া সহজ।

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

বিকাশ জটিলতা এবং সমস্যা সমাধান আমার গ্রিপের একমাত্র দিক।

এখন আসুন স্কেলেবিলিটি নিয়ে কথা বলি।

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

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

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

[সম্পাদনা]

দেখে মনে হচ্ছে এই প্রশ্নটি হঠাৎ আবার সক্রিয়, তাই এখন আমাদের কাছে নতুন মন্তব্য বৈশিষ্ট্য রয়েছে যা আমি বেশ কয়েকটি উত্তরে সরাসরি মন্তব্য করেছি। উত্তরের জন্য ধন্যবাদ, আমি মনে করি এটি একটি স্বাস্থ্যকর আলোচনা।

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

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

এমন কাউকে জিজ্ঞাসা করুন যিনি দীর্ঘদিন ধরে শিল্পে রয়েছেন এবং দীর্ঘকালীন অ্যাপ্লিকেশনগুলির সাথে কাজ করেছেন: একটি ডাটাবেস চলাকালীন কতগুলি অ্যাপ্লিকেশন এবং ইউআই স্তর এসেছে এবং চলে গেছে? যখন ডেটাবেসে 4 বা 5 টি ভিন্ন ভিন্ন অধ্যবসায় স্তরগুলি এসকিউএল উত্পন্ন করে থাকে তখন কোনও ডাটাবেস টিউন ও রিফ্যাক্টর করা কতটা কঠিন? আপনি কিছু পরিবর্তন করতে পারবেন না! ওআরএম বা যে কোনও কোড যা এসকিউএল উত্পন্ন করে আপনার ডেটাবেসকে পাথরে লক করে


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

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

"উদ্ভাবক গ্রাহকরা প্রায়শই হতাশ হন" " - অভিজ্ঞতার সাথে কেউ
Uurur Gümüşhan

আমি ২৫০০ এরও বেশি এসপিআরসি সহ একটি সিস্টেম উত্তরাধিকার সূত্রে পেয়েছি যেখানে অ্যাপ্লিকেশনটিকে কেবল স্প্রোকসকে সক্রিয় করার এবং তাদের আউটপুটটি বোঝার উপায় হিসাবে দেখা হয়। প্রতিটি ডেটা পড়া এবং লেখার নিজস্ব স্প্রোক থাকে। কোনও নিয়ন্ত্রণের পয়েন্ট নেই। এটি ঘৃণ্য এবং গ্রানাইট হিসাবে প্রায় ক্ষয়যোগ্য। আমি ডাটাবেস অপ্টিমাইজ করার বিবেচনা করি। 2500 স্প্রোকস আমাকে আমার জায়গায় রেখে দিয়েছে। সুবিন্যস্ত ডোমেন স্তর এবং পুনঃব্যবহারযোগ্য ডাল কোড সহ এমন একটি সিস্টেমের সাথে তুলনা করা এটি দুর্ভাগ্যজনক বলে মনে হচ্ছে এবং এটি একটি দুঃস্বপ্ন support সাধারণ কাজগুলি কয়েক ঘন্টা সময় নেয় এবং আত্মা ধ্বংসকারী। স্প্রোকগুলি উচ্চ লোড বা বিশেষ পদ্ধতির জন্য ব্যবহার করা উচিত আইএমও
ট্র্যাকার_জিম

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

উত্তর:


59

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

সুতরাং, আমি বলব যে কোনও আকারের-ফিট-সব উত্তর নেই। বিকাশকারীদের সচেতন হওয়া দরকার যে, কখনও কখনও খুব বেশি হয়ে ওঠার চেষ্টা করার ফলে এটি সমাধান হওয়ার চেয়ে আরও বেশি সমস্যা তৈরি করতে পারে।


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

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

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

5
একটি ভারসাম্য আছে। ধর্ম এড়িয়ে চলুন এবং যা কাজ করে তা চয়ন করুন।
জেফ ডেভিস

27

থিওরি বলেছে যে অত্যন্ত সম্মিলিত, আলগাভাবে মিলিত বাস্তবায়নই এগিয়ে যাওয়ার পথ।

সুতরাং আমি মনে করি আপনি সেই পদ্ধতির বিষয়ে প্রশ্ন করছেন, নামগুলি উদ্বেগগুলি পৃথক করে।

আমার এসপিএক্স.এস ফাইলগুলি ডাটাবেসের সাথে ইন্টারঅ্যাক্ট করা, কোনও স্প্রোক কল করা এবং আইডিটাআরডার বোঝা উচিত?

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

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

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

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

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


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

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

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

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

25

একটি কারণ - আপনার ডোমেন মডেলটি আপনার ডাটাবেস মডেল থেকে আলাদা করা।

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


9
আমাকে বলতে হবে যে আমি সত্যিই দ্বিমত পোষণ করছি, কমপক্ষে এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলির জন্য। ডেটা হ'ল অ্যাপ্লিকেশন।
এরিক জেড দাড়ি

3
কেন আপনি একই তথ্য দুটি পৃথক মডেল থাকতে চান?
Seun Osewa

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

1
আমি মনে করি এটি ভাল ধারণাটি খারাপভাবে প্রয়োগ হয়েছে।
জেফ ডেভিস

21

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

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

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

আমি সেই দৃশ্যের মতো যথাযথ ইউনিট টেস্টিংয়ের সাথেও ভাবতে শুরু করি যে এর মতো একটি কলাম স্থায়ী না হওয়া সমস্যা নাও হতে পারে।


3
"আপনার অ্যাপ্লিকেশনটি আপনার ডেটা নয়, ডেটা অ্যাপ্লিকেশনটির একটি শিল্পকর্ম tif" - ডেটা ছাড়াই অ্যাপ্লিকেশনটি মূল্যহীন। অ্যাপ্লিকেশন ছাড়াই ডেটাটির দুর্দান্ত মান রয়েছে। অ্যাপ্লিকেশন সব সময় আসে এবং যায় (নতুন করে লেখা হয়), কোনও অ-তুচ্ছ অ্যাপ্লিকেশনটির ডেটা সর্বদা রাখা হয়। এবং ডেটা মডেল সময়ের সাথে আশ্চর্যরূপে স্থিতিশীল থাকে।
ওবিওয়ানকেনোবি

16

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

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

কোডের প্রতিটি লাইনটিকে সন্দেহের সাথে দেখা উচিত।


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

10

আপনার প্রস্তাবিত অনুরূপ উদাহরণ সহ আমি উত্তর দিতে চাই।

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

(আমার মতে) সত্তা কোন প্রকল্পে কী নিয়ে আসে তা হ'ল:

অর্টোগোনালিটি: এক স্তরের পরিবর্তনগুলি অন্যান্য স্তরগুলিকে প্রভাবিত করতে পারে না (অবশ্যই যদি আপনি ডাটাবেসে একটি বিশাল পরিবর্তন করেন তবে এটি সমস্ত স্তরগুলির মধ্যে ছড়িয়ে পড়বে তবে বেশিরভাগ ছোট পরিবর্তনগুলি হবে না)।

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

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

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

চিয়ার্স।


2
সঞ্চিত পদ্ধতিগুলি সম্ভবত orthogonality এবং উদ্বেগের পৃথকীকরণের সর্বোত্তম উদাহরণ। যদি সঠিকভাবে ব্যবহার করা হয় তবে তারা ডেটাবেসকে পুরোপুরি encapsulate করে।
এরিক জেড দাড়ি

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

8

আমি মনে করি আপনি এই বিষয়ে "আপনি যতটা চিবিয়ে পারেন তার চেয়ে বেশি কামড় দিচ্ছেন"। টেড নিউয়ার্ড যখন তাকে " কম্পিউটার সায়েন্সের ভিয়েতনাম " নামে অভিহিত করছিলেন তখন তিনি উল্লাসিত হচ্ছিলেন না ।

একটি জিনিস যা আমি আপনাকে অবশ্যই গ্যারান্টি দিতে পারি তা হ'ল বিষয়টি সম্পর্কিত কারও দৃষ্টিভঙ্গির পরিবর্তন ঘটবে, যেমন অগণিত অন্যান্য ব্লগ, ফোরাম, পডকাস্ট ইত্যাদি ক্ষেত্রে প্রায়শই প্রমাণিত হয়েছে been

একটি বিতর্কিত বিষয় সম্পর্কে প্রকাশ্য বিভ্রান্তি এবং বিতর্ক করা অবশ্যই ঠিক আছে, এটি কেবল এতবার করা হয়েছে যে উভয় "পক্ষ" একমত পোষণ করতে রাজি হয়েছে এবং সবেমাত্র সফ্টওয়্যার লেখার ব্যাপারে সম্মত হয়েছে।

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


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

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

কি দারুন. "কম্পিউটার বিজ্ঞানের ভিয়েতনাম" নিবন্ধের লিঙ্কের জন্য +1, যা ওআরএম বনাম নন ওআরএম বিষয়টির একটি দুর্দান্ত ভূমিকা রয়েছে।
ল্যামব্যাক

7

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


বাহ, অন্য কেউ যাকে আমার মতো করে মনে করে ... আমার অ্যাপ্লিকেশনগুলি প্রায়শই ডেটা ম্যানিপুলেশন সম্পর্কে থাকে, তারা আসলে এটি করে।
অ্যালকেমিক্যাল

এই বৈশিষ্ট্যগুলি উপলব্ধ যে মন্তব্য হিসাবে এটি আরও ভাল হবে
কেসব্যাশ

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

4

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


এটি একটি মন্তব্য হিসাবে ভাল হবে
কেসব্যাশ

4

সত্তা অবজেক্টস অ্যাপ্লিকেশন স্তরে ক্যাশে করা সহজতর করতে পারে। ভাগ্য ভাল একটি ডেটারেডার ক্যাশে।


4

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

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

আমরা যদি বিশ্লেষণ, মডেল, ডিজাইন এবং বাস্তবায়নের জন্য ওও কৌশলগুলি প্রয়োগ করতে পারি আমাদের ব্যবসায়িক সমস্যাগুলি এটি অপ্রয়োজনীয় অ্যাপ্লিকেশনগুলির রক্ষণাবেক্ষণ এবং এক্সটেনসিবিলিটির জন্য একটি দুর্দান্ত সুবিধা!

আপনার সত্তা এবং আপনার টেবিলের মধ্যে পার্থক্য রয়েছে। সত্তাগুলি আপনার মডেল উপস্থাপন করা উচিত, টেবিলগুলি কেবল আপনার মডেলের ডেটা-দিকটি উপস্থাপন করে!

এটা সত্য যে তথ্য অ্যাপ্লিকেশান চেয়ে দীর্ঘতর জীবনকাল নয়, তার বিবেচনা এই উদ্ধৃতি থেকে ডেভিড Laribee : মডেল চিরতরে হয় ... ডেটা একটি সুখী পার্শ্ব প্রতিক্রিয়া।

এই বিষয়ে আরও কিছু লিঙ্ক:


1
সত্যি বলতে গেলে, আমি বিশ্বাস করতে শুরু করি যে ডেটাগুলি তার চারপাশের সফ্টওয়্যারগুলির চেয়ে বেশি দিন বেঁচে থাকে, কারণ ব্যবসায়ের সত্যিকারের বোঝার সাথে সাথে সফ্টওয়্যারটি ডিজাইনের ক্ষেত্রে প্রায়শই খুব কম মনোযোগ দেওয়া হয়।
flq

4

সত্যিই আকর্ষণীয় প্রশ্ন। সত্যিই আমি প্রমাণ করতে পারছি না কেন সত্তা ভাল। তবে আমি কেন তাদের পছন্দ করি সে সম্পর্কে আমি আমার মতামত ভাগ করতে পারি। কোড পছন্দ

void exportOrder(Order order, String fileName){...};

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

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

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

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


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

4

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

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

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

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

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


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

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

3

আমি ড্যানের জবাবটি যোগ করতে চাই যে উভয় মডেলকে পৃথক করা আপনার অ্যাপ্লিকেশনটিকে বিভিন্ন ডাটাবেস সার্ভার বা এমনকি ডেটাবেস মডেলগুলিতে চালিত করতে সক্ষম করতে পারে।


3

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

তবে যদি কোনও সত্তা অবজেক্ট না থাকে তবে তাদের সম্পর্কে খুব বেশি কথা বলা হবে না।

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

এটি বজায় রাখার সময় এটি সময় সাশ্রয় করে।

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


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

2
আমার মতে সঞ্চিত পদ্ধতি এবং একটি সত্তা মডেল পারস্পরিক একচেটিয়া নয়। সঞ্চিত পদ্ধতিগুলি আপনার সত্তার মডেলটি সঞ্চয় করার জন্য একটি প্রক্রিয়া সরবরাহ করতে পারে। প্রশ্নটি হল: আপনার ব্যবসায়িক যুক্তি কি সত্তাগুলির সাথে কাজ করে বা সরাসরি সঞ্চিত পদ্ধতিতে অ্যাক্সেস করে?
jbandi

3

আপনি এই পোস্টটি কম্প.ওবজেক্টে আকর্ষণীয় খুঁজে পেতে পারেন ।

আমি একমত বা মতবিরোধের দাবি করছি না তবে এটি আকর্ষণীয় এবং (আমার মনে হয়) এই বিষয়টির সাথে প্রাসঙ্গিক।


এটি একটি দুর্দান্ত পোস্ট। প্রায় পুরোপুরি ORM- এ আমার চিন্তাভাবনাগুলি যোগ করে।
এরিক জেড দাড়ি 1

3

একটি প্রশ্ন: আপনার সমস্ত ব্যবসায়ের যুক্তি ডাটাবেসে আটকে থাকলে আপনি কীভাবে সংযোগ বিচ্ছিন্ন অ্যাপ্লিকেশনগুলি পরিচালনা করবেন?

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

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

এটি নির্দিষ্ট শ্রেণীর পরিবেশের জন্য ঠিক আছে তবে এটি অবশ্যই এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলির পুরো বর্ণালীকে আবরণ করে না ।


2

@ জেডেকিউইপার, একটি ম্যাক্সিম আমি নিজের কাছে প্রায়ই বলি "যদি আপনার ব্যবসায়ের যুক্তি আপনার ডাটাবেসে না থাকে তবে এটি কেবল একটি সুপারিশ"। আমি মনে করি পল নীলসন তাঁর একটি বইতে এটি বলেছেন। অ্যাপ্লিকেশন স্তর এবং ইউআই আসে এবং যায়, তবে ডেটা সাধারণত খুব দীর্ঘ সময়ের জন্য বেঁচে থাকে।

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


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

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

2

আমি ইদানীং এই একই জিনিস সম্পর্কে চিন্তা করা হয়েছে; আমি কিছুক্ষণের জন্য সিএসএলএর ভারী ব্যবহারকারী ছিলাম এবং আমি বলেছিলাম যে "আপনার ব্যবসায়ের সমস্ত যুক্তি (বা কমপক্ষে যতটা সম্ভব যুক্তিসঙ্গতভাবে সম্ভব) ব্যবসায়ের প্রতিষ্ঠানে আবদ্ধ" saying

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

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

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

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


2

এরিক,

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

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

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

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


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

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

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

2

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

তবে আপনার যদি 100 টি টেবিলের সাথে একটি ডাটাবেস থাকে যা প্রতিটি সারণীর জন্য 4 টি সঞ্চিত প্রক্রিয়া সমান বেসিক CRUD ক্রিয়াকলাপের 400 টি সঞ্চিত পদ্ধতি যা রক্ষণাবেক্ষণের প্রয়োজন এবং দৃ strongly়ভাবে টাইপ না করা হয় তাই টাইপগুলির সংবেদনশীল বা ইউনিট পরীক্ষিত হতে পারে না । যখন আপনি একটি নতুন সিটিও পাবেন যিনি ওপেন সোর্স প্রচারের তালিকার এবং এসকিউএল সার্ভার থেকে আরএসবিএলকে মাইএসকিএলে পরিবর্তন করতে চান?

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

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

শুধু আমার 2 সেন্ট


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

এবং প্রতিটি টেবিলের জন্য 4 টি প্রকোপ তৈরি করা একটি খারাপ অভ্যাস। এটি আপনাকে কোনও ORM থেকে উত্পন্ন এসকিএল এর মতো ডেটা মডেলের সাথে দৃ coup়ভাবে জুড়ে দেয় যাতে এটি আপনাকে কিছুই কিনে না। প্রতিটি টেবিলে কেবল সিআরইউডি নয়, প্রসগুলি মোটা দানাদার ব্যবসায়িক ক্রিয়াকলাপ হওয়া দরকার।
এরিক জেড দাড়ি

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

2

ওও এবং আরডিবি: ইতিহাসের মধ্যে দূরত্বের সমস্যার জন্য আমি আরও একটি কোণ সরবরাহ করতে চাই।

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

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

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

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

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

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

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

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

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


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

আপনার যুক্তিটি বোধগম্য হয় তবে আমি মনে করি না যে এই ধারণাটি সঠিক sound আরডিবি দিয়ে ম্যাপ করা যায় না এমন কিছুই আমি কখনও শুনিনি।
জেফ ডেভিস

1

এই মুহুর্তে অনেক সময় নয়, তবে আমার মাথার উপরের অংশটি ...

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

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

এখানে কয়েকটি বিষয় যা আপনার মনে রাখা উচিত (আইএমও) যদিও:

  1. উত্পন্ন এসকিউএল কোডটি খারাপ (অনুসরণ ব্যতীত)। দুঃখিত, আমি জানি যে প্রচুর লোক মনে করে যে এটি একটি বিশাল সময় সাশ্রয়কারী, তবে আমি এমন কোনও সিস্টেম পাইনি যা আমি লিখতে পারি তার চেয়ে বেশি কার্যকর কোড তৈরি করতে পারে এবং প্রায়শই কোডটি কেবল ভয়ঙ্কর হয়। আপনি প্রায়শই একটি টন এসকিউএল কোড তৈরি করেন যা কখনই ব্যবহার হয় না। এখানে ব্যতিক্রমটি খুব সাধারণ নিদর্শন, যেমন লকউব টেবিলগুলির মতো। যদিও এতে প্রচুর লোক সঞ্চারিত হয়।
  2. সত্তা <> টেবিলগুলি (এমনকি প্রয়োজনীয়ভাবে লজিকাল ডেটা মডেল সত্তাও)। একটি ডেটা মডেল প্রায়শই ডেটা বিধি থাকে যা ডাটাবেসের সাথে যতটা সম্ভব ঘনিষ্ঠভাবে প্রয়োগ করা উচিত যা টেবিল সারিগুলি একে অপরের সাথে সম্পর্কিত বা অন্যান্য অনুরূপ নিয়ম যা ঘোষণামূলক আরআইয়ের জন্য খুব জটিল সেগুলি সম্পর্কেও অন্তর্ভুক্ত থাকতে পারে rules এগুলি সঞ্চিত পদ্ধতিতে পরিচালনা করা উচিত। আপনার সমস্ত সঞ্চিত প্রক্রিয়া যদি সাধারণ সিআরইউডি প্রক্স হয় তবে আপনি এটি করতে পারবেন না। তার উপরে, সিআরইউডি মডেলটি সাধারণত পারফরম্যান্সের সমস্যাগুলি তৈরি করে কারণ এটি নেটওয়ার্ক জুড়ে ডাটাবেসে রাউন্ড ট্রিপগুলি হ্রাস করে না। এটি প্রায়শই কোনও এন্টারপ্রাইজ অ্যাপ্লিকেশনের সবচেয়ে বড় বাধা।

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

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

1

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

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


1

যে অ্যাপ্লিকেশনগুলিতে ডেটা স্টোরেজ লজিক থেকে ডোমেন লজিক পৃথক রয়েছে সেগুলি কোনও ধরণের ডেটা উত্স (ডাটাবেস বা অন্যথায়) বা ইউআই (ওয়েব বা উইন্ডোজ (বা লিনাক্স ইত্যাদি)) অ্যাপ্লিকেশনটির সাথে খাপ খাইয়ে নিতে পারে।

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

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

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


0

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

আপনি যা কিছু করছেন না, এটি ওওপি নয়। এটি ভুল নয়, এটি কেবল ওওপি নয়, এবং প্রতিটি সমাধানের সমাধানগুলি সমাধানের জন্য এটি বোঝা যায় না।


ডেটা সর্বদা প্রথম আসে। আপনি কম্পিউটার প্রোগ্রাম প্রথম স্থানে রাখার কারণ এটি। সুতরাং অ্যাপ্লিকেশনগুলি ডিজাইনের ক্ষেত্রে সম্ভবত "ডাটাবেস প্রথম" একমাত্র বৈধ পদ্ধতির।
gbjbaanb

0

আকর্ষণীয় প্রশ্ন। একটি দম্পতি চিন্তা:

  1. আপনার ব্যবসায়ের সমস্ত যুক্তি যদি আপনার ডাটাবেসে থাকে তবে আপনি কীভাবে ইউনিট পরীক্ষা করবেন?
  2. আপনার অ্যাপ্লিকেশনের বেশ কয়েকটি পৃষ্ঠাকে প্রভাবিত করে বিশেষত আপনার ডাটাবেস কাঠামোর পরিবর্তিত হবে না, পুরো অ্যাপ্লিকেশনটিতে পরিবর্তনের জন্য এটি একটি বিরাট ঝামেলা হতে পারে?

0

ভাল প্রশ্ন!

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

উদাহরণ স্বরূপ,

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

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

এটি মূলত ডেটাবেস অ্যাক্সেস স্টাফের উপর একটি পাতলা ব্যহ্যাবরণ, তবে এটি এখনও আমার যখন প্রয়োজন হবে তখন এটিকে বিমূর্ত করার নমনীয়তা দেয়।


0

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


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

0

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


আমি ওওকে "ফ্লফ" হিসাবে দেখছি না। এটি গত দশক বা তারও বেশি সময় ধরে, এমএসএফটি, সান, ইত্যাদি আমাদের কখনও প্রয়োজন হবে এমন 99% জিনিস লিখেছেন। আমি ফ্রেমওয়ার্কের শীর্ষে প্রচুর স্থিতিশীল ক্লাস লেখার কারণে এটির অর্থ এই নয় যে আমি ওও ব্যবহার করছি না।
এরিক জেড দাড়ি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.