ওডিএম সহ ডিডিডি ব্যবসার যুক্তি কোথায় যাওয়া উচিত?


10

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

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

যাইহোক, এখন আমি একটি প্রকল্প শুরু করছি এবং আমি ডিডির শর্তে ভাবতে চাই।

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

আমি কি এইভাবে চিন্তাভাবনায় সঠিক, ডোডিতে সমস্ত ব্যবসায়িক যুক্তি ডিডিডি সহ অন্যথায় বলতে পারি এবং কেবলমাত্র সংগ্রহস্থলের মাধ্যমে অধ্যবসায়ের জন্য ওআরএম ব্যবহার করি?

উত্তর:


12

সুতরাং অন্য একটি ORM এ স্যুইচ আউট করা অসম্ভব হত (যেটি আমরা চাইনি))

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

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

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

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

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

আমি কি এইভাবে চিন্তাভাবনায় সঠিক, ডোডিতে সমস্ত ব্যবসায়িক যুক্তি ডিডিডি সহ অন্যথায় বলতে পারি এবং কেবলমাত্র সংগ্রহস্থলের মাধ্যমে অধ্যবসায়ের জন্য ওআরএম ব্যবহার করি?

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

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


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

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

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

1
@ জেডি ০১: আমি পরামর্শ দিচ্ছি যে আপনি কতটা এন্টারপ্রাইজ জাভা লোকেরা এটি করে তা দেখতে নীচের লিঙ্কটি একবার দেখুন। তাদের মূলত একটি ডিএও, একটি ডিটিও এবং বিও (ব্যবসায়িক অবজেক্ট) থাকে। আমার জন্য, এটি অনেকগুলি স্তর তবে নকশাটি ঠিক আছে। java.sun.com
ফ্যালকন

@ ফ্যালকন: হ্যাঁ, আমি আমার এমডিএ অবজেক্ট হিসাবে ডিটিওর লাইন ধরে ভাবছিলাম, আমি সে পথে যাব না not ডিডিডি প্লেয়ারদের প্রতিটি অংশই ডি 0-র কী অংশ রয়েছে তার একটি খপ্পর Just আবারও একবার ধন্যবাদ.
জেডি 01

3

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

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

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

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

এগুলি ছাড়াও, আমি মনে করি ফ্যালকন বেশ কিছু বলেছিল - পুরোপুরি ORM বা এমডিএ সরঞ্জামগুলিতে কিছুই আপনাকে সমৃদ্ধ ডোমেন সত্তা থেকে বিরত করে না।


হাই, আমি সক্ষমবজেক্টস ডট কম থেকে ইসি (এন্টারপ্রাইজ কোর অবজেক্টস) ব্যবহার করছি এবং এটি আপনি যেমন বর্ণনা করেছেন ঠিক তেমনই।
জেডি 01

1

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

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

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