আর্কিটেকচার (কাঠামো) -মুখী বনাম বৈশিষ্ট্য-ভিত্তিক প্রকল্প কাঠামো

Question

আমি জড়িত এই প্রকল্পটির একটি আর্কিটেকচার-ভিত্তিক প্রকল্পের ফাইল / ফোল্ডার কাঠামো রয়েছে:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

এটি সিস্টেমের আর্কিটেকচারাল দৃষ্টিকোণ থেকে একটি স্পষ্ট (উন্নয়ন দল দ্বারা প্রস্তাবিত)।

এটি একটি বৈশিষ্ট্য-ভিত্তিক কাঠামো ডিজাইনার দল দ্বারা প্রস্তাবিত হয়েছে:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

এই রূপটি ডিজাইনারদের কাছাকাছি এবং এটি কার্যকরভাবে প্রয়োগ করার জন্য একটি বৈশিষ্ট্য বর্ণনা করে।

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

ধন্যবাদ.

Comments

আমি কোনও কাঠামো বুঝতে পারি না - ইভেন্টস এবং রিকোয়েস্টগুলির মধ্যে পার্থক্য কী (এবং এইভাবে ইভেন্ট হ্যান্ডলার এবং অনুরোধ হ্যান্ডলারের)?

— পিটার বুফটন

খুব স্পষ্ট প্রশ্ন - এবং নিরপেক্ষও!

— মাইকেল কে

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

— কোডার্ট

Answer 1

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

যাইহোক, আমি পছন্দ করি আপনি কীভাবে এই প্রশ্নটি একটি নিরপেক্ষ দৃষ্টিকোণ থেকে জিজ্ঞাসা করেছেন।

Comments

একটি ক্যাভিয়েট সহ +1: ছোট প্রকল্পের জন্য, দ্বিতীয়টি আরও বড় ফাইল কাঠামো তৈরি করবে যার মধ্যে ফাইল রাখার জন্য রয়েছে to আমি তাদের জন্য প্রথমটি ব্যবহার করব।

— মাইকেল কে

@ মিশেল আমি সম্মত, তবে এক্ষেত্রে এটি একটি বিশাল প্রকল্প।

— Zzz

+1: এবং যদি আপনাকে কোনও ব্যবহারকারী / ক্লায়েন্টের সাথে কথোপকথন করতে হয় তবে পরিভাষাটি মোটামুটি সুসংগত হতে পারে।

— স্টিভেন এভার্স

Answer 2

আমি দ্বিতীয় পদ্ধতির সাথে সবসময়ই বেশি স্বাচ্ছন্দ্য বোধ করি তবে সত্যই ভাগ / বেস শ্রেণীর জন্য আমার সর্বদা সাধারণ বা সাধারণ বলে একটি "বৈশিষ্ট্য" থাকে have

দুটি পদ্ধতির সত্যই পৃথক পৃথক জিনিস রাখে, তবে "সাধারণ" ক্ষেত্র ছাড়া এটি কখনও কখনও জিনিসগুলিকে এমন জায়গাগুলিতে পৃথক করে যেগুলি তাদের পক্ষে উপযুক্ত নয়।

Comments

সাধারণ এবং সাধারণের জন্য +1 (প্রতিটি প্রকল্পের সাধারণ ইউটিলিটিস, সরঞ্জামগুলি রয়েছে ...)

— Zzz

Answer 3

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

এটি একটি বিশেষত গুরুত্বপূর্ণ সমস্যা যখন কোনও বৈশিষ্ট্যের বাস্তবায়ন একাধিক dlls, এক্সেস, ডাটাবেসগুলি বা অন্যান্য সফ্টওয়্যার টুকরোকে বিস্তৃত করে।

Comments

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

— রবার্ট হার্ভে

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

— জন ফিশার

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

— রবার্ট হার্ভে

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

— জন ফিশার

Answer 4

দুটি বিকল্পের সাথে মিল রেখে দ্বিতীয় পদ্ধতির সাথে একমত হতে হবে। প্রথমটি দেখতে কেবল নিরাকার ব্লবের মতো দেখাচ্ছে। কমপক্ষে দ্বিতীয়টির কিছু আকার রয়েছে।

এটি কতটা বড় প্রকল্পের উপর নির্ভর করে। যদি "বৈশিষ্ট্যগুলি" বড় হয় তবে তাদের প্রত্যেকের নিজস্ব স্বতন্ত্র বালতি প্রয়োজন।

Answer 5

আপনি যে পরিভাষাটি ব্যবহার করছেন তা আমি বুঝতে পারি না, তবে যেভাবেই হোক উত্তর দেওয়ার চেষ্টা করব, যেহেতু উভয় কাঠামোই ভুল পদ্ধতির বলে মনে হচ্ছে।

যদি আপনি কেবল কয়েকটি মুখ্য বৈশিষ্ট্য না পেয়ে থাকেন তবে আপনার সেগুলি বিভাগগুলিতে ভাগ করা দরকার - এবং এটি কোনও নকশায় আবশ্যক বলে মনে হয় না (যদি না নোড 1 এর উদ্দেশ্যে তৈরি করা হয় তবে "প্রকল্পের সমস্ত এক্স" পরামর্শ দেয়) অন্যথায়, এবং আমাকে বিস্মিত করে তোলে যে এটি হ'ল - কোনও নোড 2 আছে?)

আমি এই জাতীয় কিছু বিবেচনা করতে পারেন:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

অথবা এটা:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events

তবে তারা উভয়ই অনুমান করছে যা পুরোপুরি বন্ধ রয়েছে - আপনি যদি আরও বিস্তারিতভাবে আপনার প্রশ্নটি আপডেট করতে পারেন তবে আমি আমার মন পরিবর্তন করতে পারি। :)