আপনি কীভাবে আপনার প্রকল্পগুলি সংগঠিত করবেন? [বন্ধ]

148

আপনার কি প্রকল্পগুলির আয়োজনের কোনও বিশেষ স্টাইল রয়েছে?

উদাহরণস্বরূপ, বর্তমানে আমি বলিভিয়ায় এখানে বেশ কয়েকটি বিদ্যালয়ের জন্য একটি প্রকল্প তৈরি করছি, এভাবেই আমি এটির আয়োজন করেছি:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

আপনার প্রকল্পটি ঠিক কীভাবে সংগঠিত করবেন? আপনি কী এমন কিছু সংগঠিত করেছেন এবং এর জন্য গর্বিত তার উদাহরণ রয়েছে? আপনি কি সলিউশন ফলকের একটি স্ক্রিনশট ভাগ করতে পারেন?

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

সম্পাদনা:

.UI প্রকল্পে বিভিন্ন ফর্ম সংগঠিত করার বিষয়ে কী? আমি কোথায় / কীভাবে বিভিন্ন ফর্মটি গ্রুপ করব? প্রকল্পের সবগুলিকে মূল স্তরে রেখে দেওয়া একটি খারাপ ধারণা।

c#  .net  winforms  code-organization 
বাহ, একটি 450 অনুগ্রহ !?
— মতিন উলহাক
2
@ মন্টু: হ্যাঁ, আমি সত্যিই কিছু দুর্দান্ত উত্তরে আগ্রহী। :)
আপনি সি # সম্পর্কে জিজ্ঞাসা করেছেন তা স্পষ্টভাবে বলা উচিত। আমি ব্যক্তিগতভাবে কখনই ট্যাগগুলি দেখি না।
— পিথিকোস
নেট সংগ্রহস্থল আদর্শ কাঠামোর জন্য gist.github.com/davidfowl/ed7564297c61fe9ab814 দেখুন
— মাইকেল ফ্রেইজিম
2
বরাবরের মতো, এক্সওয়াইজেড কারণে অনেক ভাল প্রশ্ন বন্ধ হয়ে যায়। আমরা হয়ত আরও অনেক ভাল উত্তর পেয়েছি।
— মোহাম্মদ নুরাল্ডিন

উত্তর:

107

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

একবার তারা যখন যা যা জিজ্ঞাসা করছে তার একটি প্রাথমিক বোঝাপড়া আমি নির্ধারণ করি যে মূল তথ্যটি হ'ল তারা হস্তক্ষেপ করবে এবং সেই ডেটার জন্য একটি প্রাথমিক ডাটাবেস বিন্যাস শুরু করবে। তারপরে আমি ডেটা ঘিরে ব্যবসায়ের নিয়মগুলি সংজ্ঞায়িত করতে প্রশ্ন জিজ্ঞাসা করা শুরু করি।

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

সমস্যাটির প্রতিটি প্রান্ত সম্পর্কে আমার একবার ভাল বোঝাপড়া হয়ে গেলে আমি প্রকল্পটির কাঠামো তৈরি করতে শুরু করি যা সমস্যার সমাধানের জন্য তৈরি করা হবে।

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

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

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.
— অ্যামি প্যাটারসন
সূত্র
এখন পর্যন্ত সেরা উত্তর!
অনুগ্রহ উপভোগ করুন, আপনার উত্তর আমাকে প্রচুর পরিমাণে সাহায্য করেছিল।
3
@ অ্যামি তারা সব প্রকল্প? নাকি কেবল শীর্ষ-স্তরের আইটেম? আমি নেট থেকে মোটামুটি নতুন এবং কোনটি প্রকল্প বা প্রকল্পের উপ-ফোল্ডার হওয়া উচিত কিনা তা সিদ্ধান্ত নিতে সমস্যা হয়।
— কারসন মাইয়ার্স
1
@ কারসন মায়ার্স শীর্ষ স্তরের প্রতিটি আইটেমই প্রকল্প, দ্বিতীয় স্তরের আইটেমগুলি কোনও প্রকল্পের মধ্যে ফোল্ডার। শীর্ষ স্তরের কয়েকটি আইটেম হ'ল প্রকল্পগুলি যা llsলগুলিতে সংকলিত হয় যা অন্যান্য প্রকল্পগুলি প্রয়োজন হিসাবে রেফারেন্স করে।
— অ্যামি প্যাটারসন
3
@ অ্যামি আপনার উত্তরটি খুব পছন্দ করেছি, খুব বিস্তারিত ব্যাখ্যা। তবে আমি কিছু উদাহরণে দেখেছি যে লোকেরা একই প্রকল্পে বিভিন্ন ফোল্ডারের পরিবর্তে ডেটারোপোসিটোরি, ডেটা ক্লাসেস, পরিষেবাদি, ব্যবসা ইত্যাদিকে বিভিন্ন প্রকল্পে বিভক্ত করে। এ সম্পর্কে আপনি কী বলবেন? দুটি বিকল্পের মধ্যে সুবিধা / অসুবিধাগুলি কী কী? ধন্যবাদ!
— এমজারো
66

আমি আমার প্রকল্পগুলি স্তরগুলিতে বিভক্ত করতে পছন্দ করি

এইভাবে চক্রীয় নির্ভরতা পরিচালনা করা সহজ। আমি গ্যারান্টি দিতে পারি যে কোনও প্রকল্প ভুল হিসাবে ভিউ প্রকল্প (স্তর) আমদানি করছে না। আমি আমার স্তরগুলি সাব-স্তরগুলিতেও ভাঙ্গতে চাই। সুতরাং আমার সমস্ত সমাধানগুলির মতো প্রকল্পগুলির একটি তালিকা রয়েছে:

  • Product.Core
  • পণ্যের ধরণ
  • Product.Presenter
  • Product.Persistence
  • Product.UI
  • Product.Validation
  • Product.Report
  • Product.Web

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

— অ্যালেক্স
সূত্র
কী সম্পর্কে: পণ্য - কোর - মডেল - উপস্থাপক - অধ্যবসায় - ইউআই - বৈধকরণ - প্রতিবেদন - ওয়েব
— ড্যানিয়েল ফিশার ল্যানিব্যাকন
আমি মনে করি Coreএটি বেশ বিপজ্জনক, কারণ এটি একঘেয়ে কোড কোডের দিকে নিয়ে যায়, যেখানে বেশিরভাগ যুক্তিই ভিতরে যেতে পারে বা নাও পারে Core। উদাহরণস্বরূপ: যে যুক্তি মডেল, উপস্থাপক, দৃistence়তা, ইউআই, বৈধকরণ, প্রতিবেদন, ওয়েবের মতো মনে হয় না তা স্বাভাবিকভাবেই ছুঁড়ে ফেলা হবে Core।
— ইয়েও
@ ইয়ো এটি আপনার Coreপ্রকল্পটিকে আবর্জনার একঘেয়ে টুকরো রূপান্তরিত করে অথবা শত শত প্রকল্পযুক্ত সমাধান থেকে বাঁচিয়ে উভয় পক্ষই খেলতে পারে । এই সিদ্ধান্ত গ্রহণ করা বিকাশকের দায়িত্ব, কোনও প্রকল্প কাঠামো খারাপ কোডারদের খারাপ কাজ থেকে বাঁচাতে পারে না।
— অ্যালেক্স
1
@ প্রোগ্রামারস হ্যাঁ, সাধারণত প্রোডাক্টের অভ্যন্তরে থাকে ore কোর যেখানে আমি সিস্টেমটির "মূল" ব্যবসায়িক যুক্তি রাখি। "ইউআই বিজনেস লজিক" প্রোডাক্টে থাকা উচিত re উদাহরণস্বরূপ, যদি আপনার সিস্টেম সিদ্ধান্ত নেয় যে নির্দিষ্ট ডেটা লোড হওয়ার সময় একটি বোতাম অক্ষম করা আবশ্যক, এটাকে আমি "ইউআই বিজনেস লজিক" বলি এবং আমি সেটিকে উপস্থাপকের মধ্যে রেখে দেব। "কোর বিজনেস লজিক" হ'ল এটি আপনার মূল মডেল (বা ডোমেন মডেল) এর সাথে সরাসরি সম্পর্কিত। একটি বার্তাপ্রেরণ সিস্টেমটি সর্বোচ্চ অক্ষরের সংখ্যা ১৪০ টি বর্ণ নির্ধারণ করতে পারে, এটি একটি যুক্তি যা আপনার ব্যবসায়ের মূল অংশের অন্তর্ভুক্ত।
— অ্যালেক্স
2
ইউআই বা ওয়েব থেকে পণ্য কীভাবে আলাদা?
— দোপাট্রামন
19

প্রকল্পের আয়োজন

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

উদাহরণস্বরূপ, কখনও কখনও, কেবলমাত্র এই প্রকল্পটি থাকা, যার পুরো ফ্রেমওয়ার্ক রয়েছে (ইমেল, লগিং ইত্যাদি) যথেষ্ট:

MyCompany.Frameworks

অন্য সময়, আমি ফ্রেমওয়ার্কগুলি টুকরো টুকরো করে ফেলতে চাই, যাতে সেগুলি পৃথকভাবে আমদানি করা যায়:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

ফর্ম আয়োজন

আপনার প্রকল্পটি প্রসারিত হওয়ার সাথে সাথে একটি ইউআই প্রকল্পের আওতায় ফর্মগুলি সংগঠিত করা সত্যিই রূপান্তরিত হবে।

  • ছোট - একটি খুব সাধারণ প্রকল্পের জন্য একটি সাধারণ ফর্ম ফোল্ডার যথেষ্ট। কখনও কখনও আপনি কাঠামোগুলি ঠিক করতে পারেন ঠিক তেমনভাবে আপনি নিজের জায়গার নামকরণ করতে পারেন এবং জিনিসগুলির প্রয়োজনের চেয়ে আরও জটিল করে তুলতে পারেন।

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

মনে রাখবেন, দিনের শেষে নেমস্পেস এবং ফোল্ডারগুলি আপনাকে জিনিসগুলি আরও দ্রুত সাজানোর এবং খুঁজে পেতে সহায়তা করার জন্য রয়েছে are

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

সিস্টেম আর্কিটেকচারের দিকনির্দেশের জন্য মাইক্রোসফ্টের প্যাটার্নস এবং অনুশীলন সাইট দেখুন।

— রায়ান হেইস
সূত্র
12

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

  • Wadmt (সমাধান)
    • Wadmt.Common
    • Wadmt.Data
      • Wadmt.Data.MySql
      • Wadmt.Data.SqlServer
      • Wadmt.Data.Oracle
    • Wadmt.Domain
    • Wadmt.Services
    • Wadmt.Tests
      • Wadmt.Tests.Common
      • Wadmt.Tests.Domain
      • Wadmt.Tests.Services
      • Wadmt.Tests.Integration
    • Wadmt.Web

আশা করি এটি আপনার কাজে আসবে। বিচ্ছেদের স্তরগুলি আমাকে কিছুটা সময় নিয়েছিল took

— গ্রান্ট পালিন
সূত্র
4
আমি "Wadmt" হ্রাস করব। সিস্টেমটি শুকনো রাখুন। কনসোলে কাজ করার সময় এটি অনেক সাহায্য করে ...
— ড্যানিয়েল ফিশার ল্যানিব্যাকন
7

আপনার সমাধানগুলি সংগঠিত করার জন্য পরিকল্পনা রাখা ভাল, এবং এটি করার বিভিন্ন উপায় রয়েছে। আমাদের কয়েকটি কার্যকারিতা রয়েছে যা একাধিক প্রকল্পে ভাগ করা হয় যা আমাদের ব্যবহারকারীদের জন্য ধারাবাহিকতাও সরবরাহ করে। প্রকল্প সংস্থাটি আমরা যা করছি তার উপর নির্ভর করে। এটির মূলটিতে আমাদের থাকবে:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

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

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

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

— বেরিন লরিটস
সূত্র
6

এটি আকর্ষণীয় যে এখানে এত লোকেরা DRY কে বিবেচনা করে না। এটি আমার জীবনে কয়েকবার ঘটেছিল যে বিকাশকারীরা এমন ডিরেক্টরি কাঠামো তৈরি করেছিলেন যা এর কারণে তৈরি করতে সক্ষম হয় নি। প্রকল্পের নাম সমাধান এবং প্রকল্প ডিরেক্টরি থেকে দূরে রাখুন!

সুতরাং এখানে আমার উপায়:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests
— ড্যানিয়েল ফিশার লেনিব্যাকন
সূত্র
কি DRY? কিছু জন্য সংক্ষেপে?
— পিথিকোস
1
— পেরো পি।
2
কি Logic? Commonফোল্ডারে পাশাপাশি যুক্তি থাকতে পারে না ?
— দোপাট্রামন
1
আমি পুনরায় পরিবর্তনযোগ্য জিনিসগুলি কমন মধ্যে রেখেছি। কেউ কেউ ফ্রেমওয়ার্ক বা
— কোরও
2

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

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

এই মডিউলগুলির মধ্যে একটি হ'ল জিইউআই ( গ্রাফিকাল ইউজার ইন্টারফেস )।

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

— অস্কার মেডেরোস
সূত্র
1

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

উদাহরণ দুটি:

  1. যদি প্রকল্পটি কেবল ইনপুট ডেটার স্ক্রিনগুলি তৈরি করতে রেফার করে। সম্ভবত আমি একটি এমভিসি প্যাটার্ন ব্যবহার করব।
  2. যদি প্রকল্পটি ভারী শুল্ক UI হিসাবে ব্যবহৃত হতে থাকে যা সর্বাধিক বহুগুণ প্ল্যাটফর্মকে সমর্থন করে তবে একটি এমভিভিএম ডিজাইন প্যাটার্ন সহায়ক হয়।

মনে রাখবেন যে এগুলির প্রতিটি আপনাকে একটি নির্দিষ্ট উপায়ে আপনার প্রকল্পটি সংগঠিত করতে বাধ্য করবে।

আপনার জন্য এখানে কিছু পড়ার বিষয়:

। নেট ডিজাইনের প্যাটার্নস ।

নকশা প্যাটার্নস ।

অবজেক্ট ওরিয়েন্টেড ডিজাইন ।

আশাকরি এটা সাহায্য করবে.

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