সবাই কেন একটি ফোল্ডারে কন্ট্রোলার রাখে এবং অন্যটিতে ভিউ করে?

36

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

এই মাইক্রোসফ্ট পৃষ্ঠাটি ক্ষেত্রগুলির ধারণাটি প্রবর্তন করে। এই কৃত্রিম বিচ্ছিন্নতার কারণে অযৌক্তিক বৃহত অ্যাপগুলি কীভাবে পরিণত হয় তার একটি ভর্তি হিসাবে এটি পড়া যায়।

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

আর কেউ কি এই লড়াই করছে? কোন টিপস?

mvc asp.net-mvc

— bbsimonbb
সূত্র

3

আপনি কি মনে করেন না যে ব্যাক-এন্ড কোড ফাইলগুলি ফাইলগুলি থেকে পৃথক করা যৌক্তিক? যদি আমরা ইতিমধ্যে দিকটি নিচ্ছি তবে কেন প্রাসঙ্গিক সিএসএস এবং জাভাস্ক্রিপ্ট ফাইলগুলি একই ফোল্ডারে রাখছেন না?

— অল্টারনেটেক্স

2

আপনি যদি রিশার্পারটি Viewপান তবে কন্ট্রোলারে কল করার জন্য এফ 12 আপনাকে ভিউতে নিয়ে যায় এবং ভিউয়ের ডান ক্লিক মেনুতে প্রথম বিকল্প আপনাকে নিয়ামকের কাছে নিয়ে যায়, এবং নেভিগেশনের অভাবে পুরো সমস্যাটি সরে যায়।

— পিট কিরখাম

4

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

— বিবিসিমোনববি

2

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

— অ্যান্ডি

10

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

— বিবিসিমোনববি

38

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

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

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

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

এটি ঠিক যে নিয়ামকটি খুব দৃly়রূপে দর্শনটির সাথে মিলিত হয় এবং সম্ভবত একসাথে পরিবর্তিত হতে পারে। নির্ভরতা এবং যৌক্তিক সংযোগের মাধ্যমে মিলনের মধ্যে পার্থক্যটি স্মরণ করার জন্য আমরা সকলেই বিজ্ঞ wise কোডটির নির্ভরতাগুলি ডিউপলড হয়ে যাওয়ার কারণে এটি কম যুক্তিসঙ্গতভাবে সংযুক্ত হয় না।

— RubberDuck
সূত্র

1

রেজারের দৃষ্টিভঙ্গিগুলির জন্য নিয়ন্ত্রণের বিস্তৃত উপায় এখানে । আমি কেবল অধ্যবসায় করা উচিত।

— bbsimonbb

3

আমি চাচা ববকে x1.25 এ দেখেছি বলেছি। এটি আমাকে এই ভেবে ছেড়ে দেয় যে যদি আইটি আর্কিটেক্টরা ভবনগুলি তৈরি করে, আমরা সকলেই কিছুটা হ্রদকে একসাথে বেঁধে রাখা ছোট ছোট দলগুলিতে বাস করতাম। জীবন অগত্যা সহজ হবে না।

— bbsimonbb

1

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

— bbsimonbb

1

চাচা বব কী বর্ণনা করছেন তার একাডেমিক অংশের জন্য, বৈশিষ্ট্য-ভিত্তিক সফ্টওয়্যার বিকাশ ( fosd.net ) দেখুন।

— এনজিএম

1

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

— রাবারডাক

9

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

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

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

— অলিভার ওয়াটকিন্স
সূত্র

6

আপনার উত্তর দেওয়ার জন্য 'কেন সবাই ...?' প্রশ্ন: এখানে কয়েকটি সম্ভাব্য কারণ রয়েছে, যদিও আমি পুরোপুরি নিশ্চিত নই যে এর মধ্যে কোনটি সমন্বয় একটি আসল কারণ, কারণ এটি আসলে একটি বিষয়গত প্রশ্ন

একটি মিলে ফোল্ডার এবং নেমস্পেস কাঠামোর সাথে লজিকাল আর্কিটেকচার (মডেল, দেখুন, নিয়ামক) প্রতিলিপি করতে
ASP.net এমভিসি প্রকল্পের টেম্পলেটটি অনুসরণ করার জন্য কনভেনশন এবং সুবিধার বাইরে
নেমস্পেস অনুসারে গ্রুপ করতে, যেহেতু Controllers/ফোল্ডার একটি .Controllersনেমস্পেসে নিয়ে যাবে
ডিআই / আইওসি-তে এমন কিছু পরিস্থিতি সক্ষম করতে পারে যেখানে নিয়ামক ক্লাসগুলি এমন একটি নেমস্পেস থেকে অনুসন্ধান / স্ক্যান করা থাকে যেখানে এতে 'কন্ট্রোলার' থাকে / শেষ হয় (এটি ভুল হতে পারে)
টি 4 টেমপ্লেটগুলিকে স্ক্যান করার অনুমতি দেয় এবং মডেল এবং নিয়ন্ত্রককে ভিউ তৈরি করতে দেয়

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

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

— Bishoy
সূত্র

2

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

আরেকটি কারণ হ'ল "থিমগুলি" রাখা সহজ এবং ভিউ পাথটিতে সামান্য পরিবর্তন করে সমস্ত টেমপ্লেটগুলি স্যুইচ আউট করা ।

তৃতীয় কারণটি এমভিসি ফ্রেমওয়ার্কে ভিউ উল্লেখ করার সময় একটি সাধারণ ডিরেক্টরি প্যাটার্ন থাকা। প্রতিটি দৃশ্যের বড় দীর্ঘ পথের চেয়ে সাব-ডিরেক্টরি এবং ফাইল নির্দিষ্ট করা সহজ।

একমাত্র "টাইট কাপলিং" হওয়া উচিত:

নিয়ামক দ্বারা ভেরিয়েবলগুলি ভিউতে প্রেরণ করা হয়।
ফর্ম ক্ষেত্র বা দৃশ্যে ক্রিয়াগুলি আবার নিয়ামকের কাছে প্রেরণ করা হয়।

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

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


    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

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

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

— ফ্র্যাঙ্ক ফোর্ট
সূত্র

1

অগত্যা সকলেই এটি করে। উদাহরণস্বরূপ পাইথনের জ্যাঙ্গো কাঠামোর একটি অ্যাপের ধারণা রয়েছে, যেখানে আপনার অ্যাপ্লিকেশনটির সাব-মডিউলগুলি তাদের নিজস্ব ডিরেক্টরিতে তাদের নিজস্ব মডেল এবং ভিউ এবং টেম্পলেট সহ বাস করে (দর্শনগুলি জাজানো মূলত নিয়ন্ত্রককে ডাকে)। আমি সেই কাজগুলিকে পছন্দ করতে পছন্দ করি কারণ এর অর্থ হল যে আমি সহজেই আমার প্রকল্পগুলির সেটিংসে অ্যাপ্লিকেশন তালিকায় অন্তর্ভুক্ত করে কোনও "অ্যাপ্লিকেশন" প্যাকেজ করতে এবং প্রকল্পগুলিতে এটি পুনরায় ব্যবহার করতে পারি। বিভিন্ন অংশ কোথায় তা খুঁজে পাওয়াও সহজ। আমি যদি urls.py ফাইলটি দেখে এবং এর মতো কিছু দেখতে পাই তবে url(r'^users/', include('my_site.users.urls'))আমি জানি যে মডিউলে my_site.usersসমস্ত কোড রয়েছে যা ব্যবহারকারীদের পরিচালনা করে। আমি মডিউলগুলি দেখতে জানি my_site.users.viewsএবং my_site.users.modelsযখন দেখতে চাই যে ব্যবহারকারীরা কীভাবে তৈরি এবং প্রমাণীকৃত হয়। আমি জানি যে আমার সমস্ত রুটগুলি সংজ্ঞায়িত করা হয়েছে my_site.users.url।

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

— পাভেল পেনেভ
সূত্র

1

মনে রাখবেন যে কন্ট্রোলার এবং ভিউগুলি বিভিন্ন ফোল্ডারে রাখার জন্য মাইক্রোসফ্ট প্রস্তাবিত উপায় , যাতে অনেকে প্রস্তাবিত কাঠামো অনুসরণ করে,

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

রয়ে বলেন, এ ধরনের যেমন আপনার উপায় কাজ সম্পর্কে অনেক পোস্ট, আছে এই ।

— লো ফ্লাইং পেলিকান
সূত্র

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

— এসভিডজেন

1

নিবন্ধটি উপর ভিত্তি করে msdn.microsoft.com/en-us/library/... তাদের মতে "নিয়ন্ত্রক, সুপারিশ যা" এবং দেখা তাই, ইত্যাদি ..

— নিম্ন উড়ন্ত পেলিক্যান্

0

রেকর্ড এর জন্য

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

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

প্রকল্পের আচরণের (এক স্টোর ফ্রন্ট) নকল করার চেষ্টা করা হচ্ছে কার্গো কাল্ট।

— Magallanes
সূত্র

3

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

— মনিকাকে

1

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

— রাবারডাক

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

— ফ্লটার 8

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

— ই

হ্যাঁ এবং হ্যান্ডঅফস সর্বদা আইএমই শেষ করতে কোনও বৈশিষ্ট্য প্রয়োগ করে এমন এক জোড়া ডেভস রাখার চেয়ে বেশি খরচ করে।

— রাবারডাক