উইনফর্মে কোনও প্রকল্পটি কীভাবে সঠিকভাবে গঠন করবেন?


26

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

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

প্রকল্প ফোল্ডারটি কীভাবে পুনর্গঠন করবেন?

এই মুহুর্তে আমি এরকম কিছু নিয়ে ভাবছি:

  • ফর্মগুলির জন্য ফোল্ডার তৈরি করুন
  • ইউটিলিটি ক্লাসের জন্য ফোল্ডার তৈরি করুন
  • ক্লাসগুলির জন্য ফোল্ডার তৈরি করুন যাতে কেবলমাত্র ডেটা থাকে

ক্লাস যুক্ত করার সময় নামকরণের কনভেনশন কী?

আমি কি ক্লাসের নতুন নামকরণ করব যাতে কেবল তাদের নাম দেখে তাদের কার্যকারিতা চিহ্নিত করা যায়? উদাহরণস্বরূপ সমস্ত ফর্ম শ্রেণীর নামকরণ, যাতে তাদের নাম ফর্মের সাথে শেষ হয় । বা যদি তাদের জন্য বিশেষ ফোল্ডার তৈরি করা হয় তবে এটি কী প্রয়োজনীয় নয়?

কী করবেন, যাতে মূল ফর্মের সমস্ত কোড ফর্ম 1 সিএস-এ শেষ না হয়

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

এছাড়াও, আপনি কি এমন কোনও নিবন্ধ বা বই জানেন যা এই সমস্যাগুলি মোকাবেলা করে?

উত্তর:


24

দেখে মনে হচ্ছে আপনি কিছু সাধারণ সমস্যার মধ্যে পড়ে গেছেন, তবে চিন্তা করবেন না, সেগুলি ঠিক করা যেতে পারে :)

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

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

আপনি এখানে নিয়ন্ত্রণের মধ্যে কীভাবে যোগাযোগ পরিচালনা করবেন তা এখানে আসল কৌশল। আপনি ফর্মটিতে 30 জন ব্যবহারকারী নিয়ন্ত্রণ এলোমেলোভাবে একে অপরের রেফারেন্স ধারণ করে এবং সেগুলিতে কল করার পদ্ধতিগুলি চান না।

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

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

এটি দুর্দান্ত কারণ এখন যদি আপনি তালিকার বাক্সটি থেকে বিরক্ত হন এবং 3 ডি জুমি ম্যাজিক আই কন্ট্রোল চান তবে আপনি কেবল এটিই একই ইন্টারফেসে কোড করে এতে প্লাগ ইন করুন :)

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

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

আমরা যুক্ত করছি সমস্ত হ'ল মডেল এবং উপস্থাপক।

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

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

উপস্থাপকের নিজস্ব ইন্টারফেস থাকতে হবে না তবে আমি যাইহোক এটি তৈরি করতে চাই like আপনি উপস্থাপককে সুস্পষ্টভাবে যা করতে চান তা তৈরি করে।

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

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

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


8

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

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

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

অ্যাপ্লিকেশন উপাদানগুলির নিজের হিসাবে, আমি সাধারণত একটি ছোট অ্যাপ্লিকেশনটিতে কমপক্ষে তিনজনের লক্ষ্য করি

  • ডেটা অ্যাক্সেস লেয়ার (ডাটাবেস সংযোগ, ফাইল অ্যাক্সেস, ইত্যাদি) - অ্যাপ্লিকেশন দ্বারা ব্যবহৃত যে কোন স্ট্রাইস্ট / স্টোরেজ ডেটার জটিলতার উপর নির্ভর করে, এই এসেম্বলির বেশ কয়েকটি থাকতে পারে - আমি সম্ভবত ডাটাবেস হ্যান্ডলিংয়ের জন্য একটি পৃথক অ্যাসেমবিলি তৈরি করব (সম্ভবত এমনকি একাধিক অ্যাসেমব্লিসিগুলি যদি ডাটাবেসের সাথে ইন্টারেক্ট করে তবে কোনও জটিল বিষয় জড়িত - যেমন আপনি যদি খুব খারাপভাবে ডিজাইন করা ডাটাবেসের সাথে স্টুक्स হন তবে আপনাকে ডিবি সম্পর্কগুলি হ্যান্ডেল করার প্রয়োজন হতে পারে, সুতরাং সন্নিবেশ এবং পুনরুদ্ধারের জন্য একাধিক মডিউল লেখার জন্য এটি বোধগম্য হতে পারে)

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

  • উপস্থাপনা স্তর (অর্থাত্ জিইউআই); একটি ছোট অ্যাপ্লিকেশনটিতে, কয়েকটি সংলাপ বাক্সের সাথে কেবল একটি একক "মূল ফর্ম" থাকতে পারে যা সমস্ত একক সমাবেশে যেতে পারে - একটি বৃহত প্রয়োগের ক্ষেত্রে, জিইউআইয়ের পুরো কার্যকরী অংশগুলির জন্য পৃথক অ্যাসেম্বলি থাকতে পারে। এখানে ক্লাসগুলি ব্যবহারকারীর মিথস্ক্রিয়াটিকে কাজ করার চেয়ে আরও কিছু করবে - এটি কোনও বেসিক ইনপুট বৈধতা, কোনও অ্যানিমেশন পরিচালনা ইত্যাদি শেলের তুলনায় কিছুটা বেশি হবে etc. "কিছু" এমন কোনও ইভেন্ট / বোতাম ক্লিকগুলি এগিয়ে চলে যাবে will লজিক স্তর (সুতরাং আমার উপস্থাপনা স্তরটিতে কঠোরভাবে প্রয়োগের কোনও যুক্তি থাকবে না, তবে এটি কোনও জিইআইআই কোডের ভারকে লজিক স্তরে রাখবে না - সুতরাং কোনও অগ্রগতি বার বা অন্যান্য অভিনব স্টাফও উপস্থাপনা সমাবেশে বসবে / ies এর)

উপস্থাপনা, লজিক এবং ডেটা স্তরগুলিকে পৃথক সমাবেশে বিভক্ত করার জন্য আমার মূল যুক্তিটি হ'ল: আমি অনুভব করি যে আপনার ডাটাবেস বা আপনার জিইউআই ছাড়াই মূল অ্যাপ্লিকেশন লজিক চালাতে সক্ষম হওয়াই ভাল।

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

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

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


4

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

ক্লাস যুক্ত করার সময় নামকরণের কনভেনশন কী?

অবশ্যই, আপনি ফর্মের বাইরে প্রতিটি শ্রেণি পৃথক করতে চান। আমি আরও সুপারিশ করব ক্লাস প্রতি ফাইল (যদিও এমএস উদাহরণস্বরূপ EF এর জন্য উত্পন্ন কোডে তা করে না)।

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

নামকরণের ক্লাসগুলির জন্য অনেকগুলি উত্স রয়েছে, উদাহরণস্বরূপ: নেট নামকরণ কনভেনশন এবং প্রোগ্রামিং স্ট্যান্ডার্ডগুলি একবার দেখুন - সেরা অভ্যাস এবং / অথবা STOVF-C # কোডিং গাইডলাইনস

কী করবেন, যাতে মূল ফর্মের সমস্ত কোড ফর্ম 1 সিএস-এ শেষ না হয়

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

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


2

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

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

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


1

কোনও প্রকল্পের কাঠামো পুরোপুরি প্রকল্প এবং তার আকারের উপর নির্ভর করে তবে আপনি কয়েকটি ফোল্ডার যুক্ত করতে পারেন উদাহরণস্বরূপ

  • প্রচলিত (ক্লাসযুক্ত ক্লাবগুলি যেমন উপযোগিতা)
  • ডেটা অ্যাক্সেস (এসকিউএল বা অন্য কোনও ডাটাবেস সার্ভার আপনার ব্যবহার করে ডেটা অ্যাক্সেস সম্পর্কিত ক্লাস)
  • স্টাইলস (যদি আপনি আপনার প্রকল্পে কোনও সিএসএস ফাইল পেয়ে থাকেন)
  • সংস্থানসমূহ (যেমন চিত্র, সংস্থান ফাইল)
  • ওয়ার্কফ্লো (আপনার যদি থাকে তবে ওয়ার্কফ্লো সম্পর্কিত ক্লাস)

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

নামকরণের কনভেনশনটি হ'ল যদি আপনার শ্রেণি "হ্যালো ওয়ার্ল্ড" বার্তা প্রিন্ট করে থাকে তবে শ্রেণীর নামটি কার্যের সাথে সম্পর্কিত কিছু হতে হবে এবং শ্রেণীর যথাযথ নাম হ্যালোওয়ার্ল্ড। সি।

আপনি যেমন অঞ্চলগুলি তৈরি করতে পারেন

#region Hello এবং তারপরে endregionশেষে

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

বই? ERM।

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

আশা করি এটি সাহায্য করেছে!

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