তারিখ-কোডের গন্ধের ভিত্তিতে ইউআই (বা অন্যান্য) বৈশিষ্ট্যগুলি চালু এবং বন্ধ করা হয়?

11

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

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

সময় ভিত্তিক ইউআই থাকার অনুশীলনটিতে কি বহুল স্বীকৃত অনুশীলন বৈশিষ্ট্য রয়েছে এবং যদি তা না হয় তবে সেই ক্রিয়াটি অনুসরণ করার জ্ঞাত ঝুঁকিগুলি কী কী?

— NMrt
সূত্র

13

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

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

1

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

— jpmc26

22

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

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

(নোট যে বিপরীত - অপ একটি নির্দিষ্ট সময় পর abling বৈশিষ্ট্য - কোনো-কোনো, যদি না আপনি পরিষ্কারভাবে যোগাযোগ করেছেন তা যে আপনি একটি সময় সীমিত ট্রায়াল সংস্করণ বিক্রয় করছেন একটি প্রধান ধরনের তৈরি করা হচ্ছে। সময় বোমা অন্য কোন পরিস্থিতির অধীন মানুষের ঘৃণা করতে হবে আপনি অন্য যে কোনও কিছুর চেয়ে দ্রুত।)

— কিলিয়ান ফথ
সূত্র

2

The UI has no business knowing the business rule about what was published when- ঠিক আছে, তবে স্ট্যাক এক্সচেঞ্জেরও এ জাতীয় ইউআই বিধি রয়েছে। উদাহরণস্বরূপ, দুই দিন অতিবাহিত না হওয়া অবধি বন্ধ প্রশ্নগুলিতে অন্যান্য ব্যবহারকারীদের জন্য "মুছুন" লিঙ্কটি উপস্থিত হয় না এবং মাইগ্রেশন বিকল্পটি 60 দিনের পরে অক্ষম করা হয়।

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

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

— এনএমআরটি

13

@ রবার্ট হার্ভে, কিন্তু এটি কীভাবে প্রোগ্রাম করা হয়েছে? এটা কি কিছু মত if (showDelete) { <button>delete</button> }নাকি if ((post.date - today).days > 2) { <button>delete</button> }?

— আর্টুরো টরেস সানচেজ

@ আর্টুরো টরেস সানচেজ: প্রাক্তন - পুরো ধারণাটি হ'ল ব্যবসায়ের যুক্তি (যেমন ডেট ক্যালকুলেশন) সার্ভারে স্থাপন করা। যাইহোক, এটি নিজের :-) এর একটি ভাল প্রশ্ন করবে।

— সলেসকে

11

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

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

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

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

— কার্ল বিলেফেল্ট
সূত্র

6

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

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

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

— gbjbaanb
সূত্র

5

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

— ম্যাসন হুইলার
সূত্র

3

যদি পরিবর্তনগুলি তারিখ-সংবেদনশীল কিছু নির্দিষ্ট ব্যবসায়ের উদ্দেশ্যে হয়, তবে এটি একটি প্রয়োজনীয় মন্দ।

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

— রবার্ট হার্ভে
সূত্র

1

"সঠিক সময়ে আপডেট আপডেট করা আরও ভাল" নিতপিক: অগত্যা ... উদাহরণস্বরূপ, মোতায়েনের জন্য ডাউনটাইম প্রয়োজন হতে পারে, যা স্যুইচটি করা উচিত সেই সময়ে ব্যবহারিক নয়। অথবা হতে পারে সমান্তরাল ব্যবহারের কিছু সময় থাকবে ... এটি সত্যই নির্ভর করে।

— স্লেসকে

অথবা হতে পারে আপনি বড়দিনের দিন একটি "প্লে জিঙল বেলস" বোতামটি রাখতে চান। আপনি প্রতিটি ক্রিসমাস লাগাতে নাও চাইতে পারেন।

— ষাট ফুটারসুডে

2

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

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

জানা ঝুঁকি: সবচেয়ে বড় ঝুঁকিটি সম্ভবত বিভিন্ন কনফিগারেশনে ইউআই পরীক্ষা করা। আপনি যদি বিভিন্ন গ্রুপের ব্যবহারকারীদের জন্য ইউআই বৈশিষ্ট্যগুলি সক্ষম / অক্ষম করার পথে নামতে শুরু করেন তবে আপনি দ্রুত কনফিগারেশনের বিস্ফোরণ পেতে পারেন।

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

— JacquesB
সূত্র

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

— সলেসকে

2

আপনি যা বর্ণনা করছেন তা কার্যকর ডেটিংয়ের ধারণা , যা কোনওভাবেই কোনও অভিনব ধারণা নয় এবং এর মূল অংশে এক ধরণের টেম্পোরাল সমস্যা রয়েছে যার প্রতি আপনি একটি অস্থায়ী প্যাটার্ন প্রয়োগ করতে পারেন ।

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

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

— ravibhagw
সূত্র

1

তারিখের উপর ভিত্তি করে এটি অ্যাক্টিভেশন সহ একটি বৈশিষ্ট্য টগল - যা পুরোপুরি বৈধ। ভাবুন যে বৈশিষ্ট্যটি কেবলমাত্র প্রচারের সময়কালে ব্যবহারের জন্য ছিল বা কোনও নতুন তারিখে কোনও নতুন সরকার নিয়ন্ত্রণ শুরু করলে শেষ হতে হয়েছিল।

আপনি এপিএস.এনইটি এবং জাভাস্ক্রিপ্টে কাজ করছেন, তবে জাভা বৈশিষ্ট্য-টগল ফ্রেম ওয়ার্ক টোগল্জের বিশেষভাবে একটি তারিখ (এবং সময়!) ভিত্তিক অ্যাক্টিভেশন নিয়ম রয়েছে ।

— user11393
সূত্র