নামকরণ কনভেনশনগুলি ডাল, বিএএল এবং ইউআই স্তর [বন্ধ]


35

আমি নিম্নলিখিত স্তরগুলি সহ একটি সাধারণ ওয়েব অ্যাপ্লিকেশন বিকাশ করছি

  1. ইউআই স্তর (এমভিসি)
  2. ব্যবসায় যুক্তিযুক্ত স্তর (বিএল)
  3. ডেটা অ্যাক্সেস স্তর (ডাল)

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

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

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



1
আপনি কি নেমস্পেস ব্যবহার করছেন?
জেফো

উত্তর:


48

মুখবন্ধ

আশা করি এটি সুস্পষ্ট, তবে ... নীচের প্রস্তাবিত নেমস্পেসগুলিতে, আপনি প্রতিস্থাপন করবেন MyCompanyএবং MyProjectআপনার সংস্থা এবং প্রকল্পের প্রকৃত নাম সহ।

DTOs

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

উদাহরণ: Person, Address,Product

নির্ভরতা: কোনওটি নয় (স্ট্যান্ডার্ড। নেট বা সহায়ক লাইব্রেরি ব্যতীত)

ডাল

এখানে আমার ব্যক্তিগত পছন্দটি হল ডিটিও ক্লাসগুলির সাথে মিলে ড্যাল ক্লাসের এক-এক-এক সেট ব্যবহার করা, তবে একটি MyCompany.MyProject.DataAccessনেমস্পেস / প্রকল্পে। Engineদ্বন্দ্ব এড়াতে শ্রেণীর নামগুলি প্রত্যয় দিয়ে শেষ হয় । (যদি আপনি এই শব্দটি পছন্দ করেন না, তবে একটি DataAccessপ্রত্যয়টিও ভাল কাজ করবে you আপনি যা পছন্দ করেন তার সাথে সামঞ্জস্য রাখুন)) প্রতিটি ক্লাসটি বেশিরভাগ ইনপুট পরামিতি এবং রিটার্নের ধরণের জন্য ডিটিও ক্লাস ব্যবহার করে ডাটাবেসগুলিতে হিট করা সহজ সিআরইউডি বিকল্প সরবরাহ করে (ভিতরে একটি জেনেরিক Listযখন একের বেশি থাকে যেমন, কোনও Find()পদ্ধতি থেকে প্রত্যাবর্তন )।

উদাহরণ: PersonEngine, AddressEngine,ProductEngine

নির্ভরতা: MyCompany.MyProject.Models

আওয়ামী লীগ / BLL

এছাড়াও এখানে একের জন্য একের জন্য ম্যাপিং, তবে একটি MyCompany.MyProject.Logicনেমস্পেস / প্রকল্পে এবং ক্লাসগুলি Logicপ্রত্যয় পেয়েছে । এই ডাল ডাকে একমাত্র স্তর হওয়া উচিত ! এখানকার ক্লাসগুলি প্রায়শই ডএএল-এ কেবল একটি সহজ পাস-মাধ্যমে হয় তবে যদি & যখন ব্যবসায়ের নিয়মগুলি প্রয়োগ করা দরকার হয়, এটি এটির জন্য জায়গা।

উদাহরণ: PersonLogic, AddressLogic,ProductLogic

নির্ভরতা: MyCompany.MyProject.Models,MyCompany.MyProject.DataAccess

এপিআই

যদি কোনও ওয়েব পরিষেবাদির এপিআই স্তর থাকে তবে আমি ক্লাস প্রত্যয় হিসাবে একই নামের এক-জন্য-এক পদ্ধতির ব্যবহার করি তবে একটি MyCompany.MyProject.WebApiনেমস্পেস / প্রকল্পে Services। (আপনি যদি এএসপি.নেট ওয়েব এপিআই ব্যবহার না করেন তবে আপনি অবশ্যই এর Controllerপরিবর্তে প্রত্যয় ব্যবহার করবেন)।

উদাহরণ: PersonServices, AddressServices,ProductServices

নির্ভরতা: MyCompany.MyProject.Models, MyCompany.MyProject.Logic(এই বাইপাস কখনো ডাল সরাসরি কল করে!)

ব্যবসায় যুক্তি সম্পর্কিত একটি পর্যবেক্ষণ

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

এন্টারপ্রাইজ-স্তরের আর্কিটেকচারের একটি চূড়ান্ত নোট

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


2
আমি জানি এটি একটি প্রাচীন পোস্ট তবে স্বীকৃতির চেতনায়। আমি কেবল এটিই বলতে চেয়েছিলাম যে আমি এটি একটি বিষয়টিতে কার্যকরভাবে সংক্ষিপ্ত বলে মনে করেছি যা বিতর্ককে অনেকটা ফেলে দেয়। এটি ভাগ করে নেওয়ার জন্য ধন্যবাদ!
জেমস শ

7

আমি সাধারণত হিসাবে অ্যাপ্লিকেশন নির্মাণ

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

এটি শার্প-লাইটের সাথে কিছুটা মিল ।

উপসর্গ সম্পর্কে, আমি তাদের ঘৃণা করি। মাইক্রোসফ্টের অভ্যন্তরীণ কোডিং গাইডলাইনগুলি এগুলিকে ঘৃণা করে। এছাড়াও স্টাইলকপ নামে একটি সরঞ্জাম রয়েছে যা উপসর্গ সম্পর্কেও অভিযোগ করে।


পয়েন্টারের জন্য ধন্যবাদ, তবে আমার প্রধান সমস্যাটি হ'ল উপসর্গগুলি ব্যবহার না করে কখনও কখনও কোন ক্লাসটি কোথা থেকে আসে তা নির্ধারণ করা কঠিন, উদাহরণস্বরূপ আমার সাথে সংযোগ থেকে একটি ক্লাস আহ্বান করা হয়েছে এবং এটি অনেকগুলি বিভ্রান্তির কারণ হয়ে দাঁড়িয়েছে, তবে যদি আমার ছিল একটি উপসর্গ ব্যবহার করা অনেক সহজ হতে পারে।
user3631883
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.