এএসপি.নেট ওয়েবফোর্স অ্যাপ্লিকেশনটির জন্য সেরা আর্কিটেকচার


10

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

কার্যকারিতায়

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

বর্তমান শিল্প

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

প্রশ্ন

রিফ্যাক্টরিংয়ের লক্ষ্যটি হবে সাইটটিকে স্কেলযোগ্য, সহজেই রক্ষণাবেক্ষণযোগ্য এবং সুরক্ষিত করা।

  1. এর জন্য কী ধরণের আর্কিটেকচার সবচেয়ে ভাল হবে? আমার ডিটিও / পোকো / অ্যাক্টিভ রেকর্ড প্যাটার্ন ইত্যাদি ব্যবহার করা উচিত কিনা তা প্রতিটি স্তরে কী থাকতে হবে তা দয়া করে বর্ণনা করুন

  2. ডিটিও / বিওগুলি স্বয়ংক্রিয়ভাবে উত্পন্ন করার জন্য কি একটি শক্তিশালী উপায় রয়েছে যাতে অতিরিক্ত স্তরগুলি সত্ত্বেও ভবিষ্যতের যে কোনও বর্ধনগুলি কার্যকর করা সহজ হয়?

  3. প্রকল্পটি ওয়েবফর্ম থেকে এমভিসিতে রূপান্তর করা কি উপকারী হবে?


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

2
আপনার ওয়ার্কিং প্রজেক্ট প্রযুক্তিটি কেবল নতুন জাইজেড প্রযুক্তিতে পরিবর্তন করবেন না কারণ এটি রয়েছে কারণ বিশেষত যদি আপনার প্রকল্পটি ঠিকঠাকভাবে কাজ করে। যদি এটি কাজ করে তবে তা ভাঙবেন না। ব্যবসায় কোড সম্পর্কে চিন্তা করে না। কার্যকারিতা দিনের শেষে যা কিছু গুরুত্বপূর্ণ তা।
NoChance

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

এখনও অগোছালো মনে হচ্ছে: 1) ইউআইতে ইএফ অবজেক্টস (ইউআই লেয়ারে ফাইলগুলির পিছনে কোড)
স্ট্যাক ম্যান

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

উত্তর:


5

ASP.NET এমভিপি প্যাটার্নটি দীর্ঘমেয়াদী এএসপি.নেট ওয়েবফোর্স অ্যাপ্লিকেশনটির জন্য সেরা আর্কিটেকচার । এটি "উদ্বেগের বিচ্ছেদ" ধারণাটি নিয়ে আসে, যা এমভি * নিদর্শনগুলির পিছনে একটি প্রবণতা de

এটি কেন ব্যবহার করবেন তা নিয়ে প্রশ্ন ? - এই পোস্টে বিশদে সম্বোধন করা - এএসপি.নেট এমভিপি


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

ভাল, এটি একটি এমভিপি (মডেল-ভিউ-উপস্থাপক) প্যাটার্ন এবং এমভিসি (মডেল-ভিউ-কন্ট্রোলার) নয়।
ইউসুবভ

1
ওহ দুঃখিত - আমি ভুল পড়েছি আপনাকে ধন্যবাদ - আমি এমভিপি ডিজাইন সম্পর্কে পড়ব।
লোক

কোনও সমস্যা নেই, আমি আশা করি আপনি যা খুঁজছেন তা
পেয়ে যাবেন

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

1
  1. পৃথক এবং যুক্তি এবং ইউআইয়ের জন্য এমভিপি প্যাটার্ন ব্যবহার করুন, যাতে ভবিষ্যতে আপনি বিদ্যমান যুক্তিটিকে পুনরায় ব্যবহার করে একটি ভিন্ন ইউআই প্রযুক্তিতে যেতে পারেন
  2. বিএল এবং ডালের মধ্যে সংগ্রহস্থল প্যাটার্নটি ব্যবহার করুন যাতে আপনি ব্যবসায়ের যুক্তি পুনরায় ব্যবহার করে যে কোনও আরডিবিএসে পরিবর্তন করতে পারেন
  3. বিও এবং ডালের জন্য পৃথক স্তর (ডেলস) আনুন যা রক্ষণাবেক্ষণকে হ্রাস করছে।

কেউ কেন এই প্রশ্নটিতে ভোট দিয়েছে তা নিশ্চিত নয়। সত্যি কথা বলতে কি, এটি সবচেয়ে সংক্ষিপ্ত উত্তর। +1
গ্রেগ বার্গার্ট

0

এল ইউসুবভ যেমন উল্লেখ করেছেন, এমভিপি প্যাটার্নটি দুর্দান্ত হতে পারে।

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

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

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

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

সম্পাদন করা

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

এটি কেবল একটি ক্লিনার পৃথকীকরণ নয় এটি আপনার কোডটি স্ব নথিরও উপায় হতে পারে। যখন কেউ আপনার কোড পড়েন তখন তারা আপনাকে একটি নিবন্ধকরণ বস্তুতে কল করতে দেখেন যাতে আপনি ঠিক কীভাবে চলছেন তা জানেন।

আপনি যদি এমভিপি প্যাটার্নটি কঠোরভাবে অনুসরণ করতে চান, তবে রেজিস্ট্রেশন অবজেক্টটিতে পরামিতিগুলি পাস করার পরিবর্তে কোড-পেছন একটি ইন্টারফেস প্রয়োগ করবে। ইন্টারফেসের প্রয়োগটি ইন্টারফেসে মূলত সমস্ত দর্শনীয় বস্তু (পাঠ্য ক্ষেত্র ইত্যাদি) ম্যাপ করে। যেমন পাবলিক স্ট্রিং ফার্স্টনাম {get {রিটার্ন txtFirstName.Text; }}

এটি হয়ে গেলে আপনি পৃষ্ঠাটি রেজিস্ট্রেশন অবজেক্টে পাস করতে পারেন

Registration.RegisterUser (এই);

এবং এই RegisterUser পদ্ধতিটি ইন্টারফেসটিকে প্যারামিটার হিসাবে গ্রহণ করবে

পাবলিক বুল রেজিস্টারউজার (আইউজার ব্যবহারকারী) {ব্যবহারকারীর প্রথম নাম ...

পাবলিক ইন্টারফেস IUser {পাবলিক স্ট্রিং ফার্স্টনাম; }

যদি এই এমভিপি বিভ্রান্তিকর মনে হয় তবে কেবল রিফ্যাক্টরিংয়ের দিকে মনোনিবেশ করুন এবং কোড-পুনঃব্যবহারকে সর্বাধিকীকরণ করা এই সমস্তের মূল বিষয়টি জানেন। নিজেকে পুনরাবৃত্তি করার পরে আর কিছুই নেই। এটাই ডিআরওয়াই অধ্যক্ষ


আপনার সহায়ক টিপস জন্য ধন্যবাদ। হ্যাঁ, আমি অবশ্যই এ নিয়ে কিছুটা অভিভূত হয়েছি। আমার কাছে মনে হয় এমভিসি ব্যবহারের সেরা প্যাটার্ন হবে তবে এমভিপি অর্জন করা সহজ হবে এবং পরবর্তী সেরা প্যাটার্ন হবে be আমি ফাইলগুলির পিছনে সর্বদা কোড ব্যবহার করেছি তাই ব্যবসায়ের যুক্তি উপস্থাপনা থেকে কীভাবে পৃথক করা যায় তা সম্পর্কে সর্বদা আমার মাথা আঁচড়ান ... সুতরাং আমার .aspx.cs ফাইলগুলিকে ডোমেন স্তরে সরিয়ে নিয়ে যেতে সক্ষম হওয়া উচিত এবং এসপেক্সে উত্তরাধিকার সূত্র থাকতে হবে ? অবশ্যই 3 স্তর সহ শেষ হওয়া আমার 1 ম সংস্করণটি প্রকাশের সাথে স্বাচ্ছন্দ্য বোধ করবে - তবে আমি সেখান থেকে এটিকে উন্নত করতে পারি।
লোকটি

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