কী কীভাবে তার নিজস্ব কন্ট্রোলার পাওয়া উচিত তা নির্ধারণ করবেন?


10

আমি পিএইচপি দিয়ে নির্মিত আমার ওয়েব অ্যাপ্লিকেশনটিতে এমভিসি প্যাটার্ন ব্যবহার করছি।

আমি ক্রিয়া সেট করার জন্য আমাকে নতুন ডেডিকেটেড কন্ট্রোলার প্রয়োজন কিনা বা যদি আমি সেগুলি ইতিমধ্যে বিদ্যমান কন্ট্রোলারের মধ্যে রাখি তবে তা নির্ধারণের জন্য আমি সর্বদা লড়াই করে যাচ্ছি।

কন্ট্রোলার তৈরি করার সময় কি থাম্বের কোনও ভাল নিয়ম অনুসরণ করা উচিত?

উদাহরণস্বরূপ আমার থাকতে পারে:

AuthenticationController ক্রিয়া সহ:

  • index() লগইন ফর্ম প্রদর্শন করতে।
  • submit() ফর্ম জমা হ্যান্ডেল করতে।
  • logout(), স্ব-ব্যাখ্যামূলক।

অথবা

LoginController ক্রিয়া সহ:

  • index() লগইন ফর্ম প্রদর্শন করতে।
  • submit() ফর্ম জমা হ্যান্ডেল করতে।

LogoutController ক্রিয়া সহ:

  • index() লগ আউট পরিচালনা করতে।

অথবা

AccountController ক্রিয়া সহ:

  • loginGet() লগইন ফর্ম প্রদর্শন করতে।
  • loginPost() লগইন ফর্ম জমা পরিচালনা করতে।
  • logoutGet() লগ আউট পরিচালনা করতে।
  • registerGet() নিবন্ধন ফর্ম প্রদর্শন করতে।
  • registerPost() ফর্ম জমা হ্যান্ডেল করতে।

    এবং অন্য কোনও ক্রিয়াকলাপ যা কোনও অ্যাকাউন্টের সাথে জড়িত।


RESTful ডিজাইনের দিকে একবার নজর দিন। এটি এই ধরণের প্রতিটি একক সমস্যা সমাধান করে না, তবে কীভাবে এটি সম্পর্কে চিন্তা করা যায় তা আপনাকে একটি খুব ভাল দিকনির্দেশ দেয়।
Thorsten müller

উত্তর:


3

নিয়ন্ত্রকদের সঠিক গ্রুপিং সন্ধানের জন্য, পরীক্ষার কথা ভাবেন

(এমনকি আপনি যদি কোনও পরীক্ষা নাও করেন তবে আপনার কন্ট্রোলারদের পরীক্ষা করার বিষয়ে আপনি কীভাবে যাবেন তা ভেবে আপনাকে সেগুলি কীভাবে গঠন করা যায় সে সম্পর্কে আপনাকে খুব ভাল অন্তর্দৃষ্টি দেওয়া হবে))

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

LoginControllerএকই কারণে অযোগ্য: আপনি প্রথমে অ্যাকাউন্ট তৈরি না করে এটি পরীক্ষা করতে পারবেন না, এবং আরও অনেকগুলি বিষয় যা আপনি পরীক্ষা করতে পারবেন না যেমন উদাহরণস্বরূপ সদৃশ লগইনগুলি প্রতিরোধ করা তবে লগ আউট করার পরে কোনও ব্যবহারকারীকে লগইন করার অনুমতি দেওয়া। (যেহেতু এই নিয়ামকের কোনও লগআউট কার্যকারিতা নেই))

একটি AccountControllerআপনার পরীক্ষাটি করার জন্য আপনাকে যা যা প্রয়োজন তা আপনাকে দেবে: আপনি একটি পরীক্ষা অ্যাকাউন্ট তৈরি করতে পারেন এবং তারপরে লগইন করার চেষ্টা করতে পারেন, আপনি অ্যাকাউন্টটি মুছতে পারেন এবং তারপরে আপনি আরও লগইন করতে পারবেন না তা নিশ্চিত করতে পারেন, আপনি পাসওয়ার্ড পরিবর্তন করতে পারেন এবং নিশ্চিত করতে পারেন যে লগইন করার জন্য ডান পাসওয়ার্ড ব্যবহার করতে হবে, ইত্যাদি etc.

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

এবং সাধারণভাবে বলতে গেলে, "পরীক্ষার চিন্তা করুন" পদ্ধতিটি কেবল এই নির্দিষ্ট দৃশ্যেই কাজ করবে না, তবে ভবিষ্যতে যে কোনও অনুরূপ দৃশ্যে আপনি আসতে পারেন।


1

উত্তর যে সুস্পষ্ট নয়

আমি কোনও উত্তর দেওয়ার বক্তব্য দেওয়ার আগে দয়া করে আমাকে কয়েকটি বিষয় পরিষ্কার করতে দিন। সবার আগে:

নিয়ামক কি?

কন্ট্রোলার সিস্টেমের একটি অংশ যা অনুরোধকে নিয়ন্ত্রণ করে - প্রেরণের পরে। সুতরাং, আমরা এটি সম্পর্কিত কিছু ক্রিয়াকলাপ হিসাবে সংজ্ঞায়িত করতে পারি ... কি?

নিয়ামকের সুযোগ কী?

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

উত্তরটা হচ্ছে...

ক্রিয়া সহ প্রমাণীকরণ নিয়ন্ত্রণকারী:

  • সূচী () লগইন ফর্ম প্রদর্শন করতে।
  • জমা দিন () ফর্ম জমা পরিচালনা করতে।
  • লগআউট (), স্ব-ব্যাখ্যামূলক।

না, প্রমাণীকরণ একটি প্রক্রিয়া। সে পথে যাবেন না।

ক্রিয়া সহ লগইনকন্ট্রোলার:

  • সূচী () লগইন ফর্ম প্রদর্শন করতে।
  • জমা দিন () ফর্ম জমা পরিচালনা করতে।

একই অবস্থা. লগইন - ক্রিয়া। অ্যাকশন নিয়ামক তৈরি করা ভাল না (আপনার এটির সাথে সম্পর্কিত মডেল নেই)।

ক্রিয়াকলাপ সহ অ্যাকাউন্টকন্ট্রোলার:

  • লগইন ফর্ম প্রদর্শন করতে লগইনগেট ()।
  • লগইন ফর্ম জমা দেওয়ার জন্য লগইনপোস্ট ()।
  • লগআউট () লগ আউট পরিচালনা করতে।
  • নিবন্ধন ফর্ম প্রদর্শন করতে নিবন্ধন করুন ()।
  • ফর্ম জমা হ্যান্ডেল করতে নিবন্ধনপোস্ট ()।

বেশ ভাল, তবে আমি নিশ্চিত নই যে নিম্ন-স্তরের নিয়ামক (কন্ট্রোলার নিজেই বিমূর্তকরণ) তৈরি করা কার্যকর। যাইহোক, * গেট বা * পোস্ট দিয়ে পদ্ধতিগুলি তৈরি করা অস্পষ্ট।

যেকোনো পরামর্শ?

হ্যাঁ, এটি বিবেচনা করুন:

AccountController:

  • লগইন (AccountModel)
  • লগ-আউট (AccountModel)
  • রেজিস্টার (AccountModel)
  • সূচক ()

এবং এটি সম্পর্কিত মডেল, ofc অ্যাকাউন্ট ক্লাস। এটি আপনাকে আপনার মডেল-কন্ট্রোলার জুটিকে অন্য কোথাও স্থানান্তরিত করার সুযোগ দেবে (যদি এটি প্রয়োজনীয় হবে) এবং একটি পরিষ্কার কোড তৈরি করুন ( login()পদ্ধতিটি কী বোঝায় তা স্পষ্ট )। মডেলটির সাথে সংযুক্ত হওয়া বিশেষত CRUD অ্যাপ্লিকেশনগুলির সাথে বিখ্যাত এবং সম্ভবত এটি আপনার পক্ষে একটি উপায়।


1

কন্ট্রোলার সাধারণত একটি নির্দিষ্ট সংস্থান (একটি সত্তা শ্রেণি, ডাটাবেস একটি টেবিল) জন্য তৈরি করা হয়, কিন্তু অ্যাপ্লিকেশন একটি নির্দিষ্ট অংশ সঙ্গে দায়ী যে ক্রিয়া একসাথে গ্রুপ তৈরি করা যেতে পারে। আপনার উদাহরণগুলিতে, এটি আ কন্ট্রোলার যা অ্যাপ্লিকেশনটির সুরক্ষা পরিচালনা করে:

class SecurityController
{
    // can handle both the login page display and
    // the login page submission
    login(); 

    logout();

    register();

    // optional: confirm account after registration
    confirm();

    // displays the forgot password page
    forgotPassword();

    // displays the reset password page
    // and handle the form submission
    resetPassword();
}

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

সংস্থাগুলির জন্য উত্সগুলির জন্য তৈরি করা হয়েছে (আসুন আমরা বলি Task) আপনার স্বাভাবিক সিআরইউডি ক্রিয়াকলাপ হবে:

class TasksController
{
    // usually displays a paginated list of tasks
    index();

    // displays a certain task, based on an identifier
    show(id);

    // displays page with form and
    // handles form submission for creating
    // new tasks
    create();

    // same as create(), but for changing records
    update(id);     

    // displays confirmation message
    // and handles submissions in case of confirmation
    delete()
}

অবশ্যই, আপনার একই নিয়ন্ত্রণকারীর সাথে সম্পর্কিত সংস্থান যুক্ত করার সম্ভাবনা রয়েছে। উদাহরণস্বরূপ বলুন আপনার সত্তা রয়েছে Businessএবং প্রত্যেকের বেশ কয়েকটি BusinessServiceসত্ত্বা রয়েছে। এর জন্য একটি নিয়ামক এর মতো দেখতে পাবেন:

class BusinessController
{
    index();

    show(id);

    create();

    update(id);

    delete();

    // display the business services for a certain business
    listBusinessServices(businessId);

    // displays a certain business service
    showBusinessService(id);

    // create a new business service for a certain business
    createBusinessService(businessId);

    // updates a certain business service
    updateBusinessService(id);

    // deletes a certain business service
    deleteBusinessService(id);
}

এই পদ্ধতির অর্থ হয় যখন সম্পর্কিত শিশুদের সত্তা পিতামাতার সত্তা ব্যতীত বিদ্যমান থাকতে পারে না।

এগুলি আমার প্রস্তাবনাগুলি:

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

এখানে আরও পড়ার জন্য কিছু সংস্থান ।


0

আমি দুটি বৈপরীত্য নকশা "বাহিনী" দেখছি (যা নিয়ামকদের একচেটিয়া নয়):

  • সংহতি - নিয়ন্ত্রকদের উচিত সম্পর্কিত ক্রিয়াকলাপগুলি গ্রুপ করা উচিত
  • সরলতা - নিয়ন্ত্রণকারীদের তাদের জটিলতা পরিচালনা করতে যতটা সম্ভব ছোট হওয়া উচিত

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

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

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

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


0

এখানে থাম্বের কয়েকটি নিয়ম রয়েছে:

  • বিষয় বা বিষয় অনুসারে সংগঠিত করুন, নিয়ামকের নাম সহ বিষয়ের নাম।

  • মনে রাখবেন যে কন্ট্রোলারের নামটি ইউআরএল-এ উপস্থিত হবে, আপনার ব্যবহারকারীদের কাছে দৃশ্যমান, তাই সম্ভবত তাদের এটিকে বোঝা উচিত।

আপনি যে পরিস্থিতিতে উল্লেখ করেছেন (প্রমাণীকরণ) এমভিসি টিম ইতিমধ্যে আপনার জন্য নিয়ামকটি লিখেছিল। ভিজ্যুয়াল স্টুডিও 2013 খুলুন এবং তারপরে ক্লিক করুন

File / New / Project... 
Search installed templates for "ASP.NET MVC4 Web Application"
Choose "Internet Application" / OK.

অ্যাকাউন্টকন্ট্রোলার.সিগুলিতে ব্যবহারকারীর অ্যাকাউন্ট পরিচালনার জন্য সমস্ত পদ্ধতি রয়েছে:

Login()
Logoff()
Register()
Disassociate()
Manage()
ExternalLogin()

সুতরাং তারা দৃশ্যমান বিষয়ের নাম "অ্যাকাউন্ট" সহ "ব্যবহারকারী অ্যাকাউন্ট এবং প্রমাণীকরণ" শীর্ষক দ্বারা সংগঠিত করেছে।


0

পরিভাষা

আমি বিশ্বাস করি যে এইচটিটিপি সম্পর্কিত কিছু পদ্ধতিতে "নিয়ামক" রয়েছে এমন একটি শ্রেণিকে কল করা একটি বড় ভুল ধারণা।

কন্ট্রোলার একটি পদ্ধতি হ্যান্ডলগুলি অনুরোধ, কিন্তু না একটি বর্গ ধরনের পদ্ধতি ধারণকারী । সুতরাং, index(), submit(), logout()কন্ট্রোলার আছে।

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

উত্তর

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

যেহেতু login, logoutএবং এই জাতীয় অন্যান্য ক্রিয়াগুলি বেশিরভাগই অধিবেশনটির সাথে সম্পর্কিত হয়, তাই সম্ভবত এটির ভিতরে রাখা ভাল SessionControllerএবং indexনিয়ামক, যা কেবল একটি ফর্ম প্রিন্ট করে LoginPageController, এটি স্থাপন করা উচিত , যেহেতু এটি লগইন পৃষ্ঠার সাথে স্পষ্টতই ডিল করে। এইচটিএমএল রেন্ডারিং এবং সেশন ম্যানেজমেন্টকে একটি একক শ্রেণিতে রাখার জন্য এটি কিছুটা অর্থবোধ করে এবং এটি এসআরপি লঙ্ঘন করে এবং সম্ভবত অন্যান্য ভাল অনুশীলনগুলির একটি গোছা।

মূলনীতি

কোডের টুকরোটি কোথায় রাখবেন তা সিদ্ধান্ত নিতে আপনার যখন সমস্যা হয় তখন আপনি যে ডেটা (এবং প্রকারগুলি) ব্যবহার করেন তার সাথে শুরু করুন।


2
দুঃখিত,
এগুলি হ'ল

@ JK01 আপনি এগুলিকে কল করেছেন Those এটা পরিভাষা, আপনি জানেন। এবং এমন ফ্রেমওয়ার্ক রয়েছে যা এই ফাংশনগুলিকে "নিয়ন্ত্রক" (বা "হ্যান্ডলার") বলে, যেহেতু অনেকগুলি ফ্রেমওয়ার্ক রয়েছে যা ক্লাসগুলিতে সেগুলি সংগঠিত করে না, যেহেতু নেমস্পেস / মডিউলগুলি ইতিমধ্যে যথেষ্ট। আপনার পছন্দ মতো যে কোনও পদ আপনি ব্যবহার করতে পারেন, এটি কেবল শব্দ, তবে আমি মনে করি কম পদ থাকা ভাল।
স্ক্রিপ্টিন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.