ওআরএমগুলি কি সমৃদ্ধ ডোমেন মডেলগুলি তৈরি করতে সক্ষম করে?


21

প্রায় ৮ বছর ধরে আমার বেশিরভাগ প্রকল্পে হাইবারনেট ব্যবহার করার পরে, আমি এমন একটি সংস্থায় নেমেছি যা এর ব্যবহারকে নিরুৎসাহিত করে এবং অ্যাপ্লিকেশনগুলি কেবল সঞ্চিত পদ্ধতিগুলির মাধ্যমে ডিবির সাথে ইন্টারঅ্যাক্ট করতে চায়।

কয়েক সপ্তাহ ধরে এটি করার পরে, আমি যে অ্যাপ্লিকেশনটি তৈরি করতে শুরু করছি তার একটি সমৃদ্ধ ডোমেন মডেল তৈরি করতে সক্ষম হয়েছি এবং অ্যাপ্লিকেশনটি কেবল (ভয়াবহ) লেনদেনের স্ক্রিপ্টের মতো দেখাচ্ছে।

আমি খুঁজে পাওয়া কিছু সমস্যা হ'ল:

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

আমার প্রশ্নগুলি হ'ল:

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

উপসংহার

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

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

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

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

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

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


ছোট আপডেট (6/6/2012)

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


ঠিক আছে, স্পষ্টতই আপনি হাইবারনেট যা করতে পারেন তা করতে পারেন এবং ডায়নামিক প্রক্সি অবজেক্ট তৈরির জন্য উত্তরাধিকার ব্যবহার করতে পারেন যা আপনাকে বস্তুর গ্রাফটি পুনরুদ্ধার করতে দেয়। এটি এসপির কাছে অত্যন্ত হ্যাকি যদিও: ডি
ম্যাক্স

সুতরাং আমি হাইবারনেট অর্ধেক পুনরায় সংবহন করব, হাইবারনেট টিমের 10+ বছরের অভিজ্ঞতা ছাড়াই :)।
অগস্টো

1
যে কোনও ডিবিএর নির্দিষ্ট ব্যবহারকারীর দ্বারা নির্দিষ্ট টেবিলগুলি বাদ দেওয়া উচিত। আপনি কীভাবে এটি করার চেষ্টা করছেন তা বিবেচ্য নয়।
জেফো

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

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

উত্তর:


16

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


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

1
@ অগস্টো ওয়েল ... আপনি অ্যাপ বিকাশকারী, তাই আপনাকে সিদ্ধান্ত নিতে হবে যে কিছু ক্ষেত্রের সাথে ন্যূনাল-এ সেট করা নির্দিষ্ট ক্ষেত্রের সাথে কিছু নির্দিষ্ট অবজেক্টের উপস্থিতি বোঝা যায় কিনা you যদি এটি উপলব্ধি করে (উদাহরণস্বরূপ কোনও নির্দিষ্ট কাজের জন্য) তবে এটি হতে দিন let যদি তা না হয় তবে এসপির লেখককে আরও ডেটা সরবরাহ করতে বলুন, যাতে আপনি নিজের অবজেক্ট তৈরি করতে পারেন।
জেসেক প্রুশিয়া

এবং জাসেকের মন্তব্যে যোগ করা - এটি 2+ সঞ্চিত প্রকোকে কল করা সত্যই পুরোপুরি গ্রহণযোগ্য, আবার আপনার দুটি ডোমেন মডেল তৈরি করতে আপনাকে কল করতে হবে এমন দুটি রিমোট সার্ভিস হিসাবে মনে করুন, :-) এর সাথে কোনও ভুল নেই।
মার্টিজন ভার্গবার্গ

@ মার্তিজন: আমার অভিজ্ঞতায় একটি পাতলা স্তর পর্যাপ্ত নয়। ম্যাপিং কোডটি অন্তর্নিহিত ব্যবসার যুক্তির চেয়ে যথেষ্ট দীর্ঘ হতে পারে।
কেভিন লাইন

@ কেভিন ক্লাইন - উত্তম বক্তব্য, উত্তরে '
আশাবাদী

5

সঞ্চিত পদ্ধতি ব্যবহার করে কি আসল উপকার পাওয়া যায়?

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


হ্যাঁ মিলিয়ন বার হ্যাঁ! আপনাকে এটিও নিশ্চিত করতে হবে যে ব্যবহারকারীরা টেবিল এবং সঞ্চিত প্রকটগুলিতে সরাসরি অধিকার না পেয়েও যেহেতু তাদের করা উচিত নয় এমন কোনও সাইনগেইন করতে পারবেন না that
এইচএলজিইএম

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

ভাঙা লিঙ্ক ...
অ্যালেক্স আর

@ অ্যালেক্সআর, স্থির লিঙ্ক
টাঙ্গুরেনা

2

সঞ্চিত পদ্ধতিগুলি ক্লায়েন্ট-সাইড এসকিউএল কোডের চেয়ে অনেক বেশি দক্ষ। তারা ডিবিতে এসকিউএল প্রাক-সংকলন করে যা এটি কিছু অপটিমাইজেশন সম্পাদন করার অনুমতি দেয়।

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

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

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


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

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

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

1
@ অগাস্টো the approach of letting the DBAs write the procedures smells like development silos+100 সত্যের এই রত্নটির জন্য আপনার সাথে বাধা সৃষ্টি করে। আমি সর্বদা এটিকে কেস হিসাবে দেখেছি যেখানে সঞ্চিত প্রক্রিয়াগুলির মাধ্যমে ডেটা অ্যাক্সেস নিয়ন্ত্রণ করা হয়েছিল।
maple_shaft

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

2

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

এটি ভুল এবং আপনার ডোমেনটি সরাসরি আপনার ডিবি স্কিমার সাথে সংযুক্ত করে।

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

এর অর্থ আপনার প্রতিটি সামগ্রীর মধ্যে ম্যাপিং দরকার।


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

@ ম্যাপেল_শ্যাফ্ট সম্মত হয়েছেন এবং এটিই আমি "ম্যাপিং" বলতে
চাইছিলাম

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

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

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

1

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


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

@ অগস্টো: ইন্টারফেস?
ক্রমিই পুনর্নির্মাণ মনিকা

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

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