আমার প্রাথমিক দিনের কাজটি HTML অ্যাপ্লিকেশন তৈরি করছে। এর সাথে আমি বোঝাতে চাইছি প্রচুর সম্পাদনযোগ্য গ্রিডভিউ, পাঠ্যবাক্স, ড্রপডাউন, ইত্যাদি সহ অভ্যন্তরীণভাবে সিআরইউডি-টাইপ অ্যাপ্লিকেশন ব্যবহৃত হয়েছে আমরা বর্তমানে এএসপি.এনইটি ওয়েবফর্ম ব্যবহার করছি, যা কাজটি সম্পন্ন করে, তবে কার্য সম্পাদন বেশিরভাগই হতাশাব্যঞ্জক, এবং বেশিরভাগ ক্ষেত্রে আপনি আপনার যা প্রয়োজন তা পেতে হুপসের মধ্য দিয়ে ঝাঁপিয়ে পড়তে হবে। হুপস যা সিলিং থেকে ঝুলানো হয়েছে এবং আগুন লাগিয়ে দেওয়া হয়েছে।
সুতরাং আমি ভাবছি যে সমস্ত ইউআইটিকে জাভাস্ক্রিপ্টের দিকে সরিয়ে নেওয়া ভাল ধারণা হতে পারে কিনা। পুনরায় ব্যবহারযোগ্য নিয়ন্ত্রণগুলির একটি শক্তিশালী সেট বিকাশ করুন যা বিশেষত আমাদের প্রয়োজন অনুসারে তৈরি করা হয়েছে এবং কেবলমাত্র সার্ভারের সাথে ডেটা আদান প্রদান করে। হ্যাঁ, আমি "নিয়ন্ত্রণ" (ওরফে "উইজেট") দৃষ্টান্ত পছন্দ করি, এটি এই জাতীয় অ্যাপ্লিকেশনগুলির পক্ষে বেশ উপযুক্ত। সুতরাং সার্ভারের পাশে আমরা আমাদের বর্তমান এএসপিএক্স মার্কআপের সাথে সাদৃশ্যযুক্ত একটি বেসিক লেআউটটি রাখতে পারব তবে এটি ক্লায়েন্টকে কেবল একবার পাঠানো হবে এবং জাভাস্ক্রিপ্ট অংশটি পরবর্তী সমস্ত ইউআই আপডেটগুলি যত্ন নেবে।
সমস্যাটি হ'ল আমি এর আগে কখনও এটি করিনি এবং আমি কখনও কাউকে এটি করতে দেখিনি, তাই সমস্যাগুলি কী হবে তা আমি জানি না। বিশেষত, আমি উদ্বিগ্ন:
- পারফরম্যান্স এখনও। বেঞ্চমার্কিং দেখায় যে বর্তমানে মূল বিলম্ব ক্লায়েন্টের পক্ষে, যখন ব্রাউজারটি একটি এজেএক্স আপডেটের পরে বেশিরভাগ পৃষ্ঠা পুনরায় রেন্ডার করার চেষ্টা করে। এএসপি.এনইটি ওয়েবফর্মগুলি উত্পাদিত মার্কআপ "ওয়েব" শব্দের একটি নতুন অর্থ দেয় এবং সমৃদ্ধ ডিভ এক্সপ্রেস নিয়ন্ত্রণগুলি তার উপরে জাভাস্ক্রিপ্ট জটিলতার নিজস্ব স্তর যুক্ত করে। তবে জাভাস্ক্রিপ্টের দিকের সমস্ত প্রয়োজনীয় পরিবর্তনগুলি পুনরায় গণনা করা এবং তারপরে কী আপডেট করা দরকার তা কেবল আপডেট করা কি দ্রুত হবে? নোট করুন যে আমি বিভিন্ন ফর্মের সাথে কথা বলছি যেখানে বেশ কয়েকটি সম্পাদনযোগ্য গ্রিডভিউ, প্রচুর পাঠ্যবাক্স, অনেকগুলি ড্রপডাউন রয়েছে যার মধ্যে প্রতিটি অর্ধ-জিলিয়ন ফিল্টারযোগ্য আইটেম রয়েছে etc.
- উন্নয়নের স্বাচ্ছন্দ্য । এখন আরও অনেক জাভাস্ক্রিপ্ট থাকবে এবং এটি সম্ভবত পৃষ্ঠার এইচটিএমএল মার্কআপের সাথে মিশে যাবে। এটি বা কোনওরকম নতুন ভিউ ইঞ্জিন তৈরি করতে হবে। জাভাস্ক্রিপ্টের জন্য ইন্টেলিজেন্স সি # কোডের চেয়েও অনেক খারাপ এবং জাভাস্ক্রিপ্টের গতিশীল প্রকৃতির কারণে এটি আরও ভাল হওয়ার আশা করা যায় না। কোডিং অনুশীলনগুলি এটি কিছুটা উন্নতি করতে পারে, তবে খুব বেশি নয়। এছাড়াও, আমাদের বিকাশকারীদের বেশিরভাগই প্রাথমিকভাবে সি # বিকাশকারী তাই কিছু শেখার বক্ররেখা এবং প্রাথমিক ভুল থাকবে।
- সুরক্ষা । অনেকগুলি সুরক্ষা চেক দু'বার করতে হবে (সার্ভার-সাইড এবং ইউআই-সাইড), এবং ডেটা-প্রসেসিং সার্ভারের পক্ষ থেকে তাদের আরও অনেক কিছু অন্তর্ভুক্ত করতে হবে। বর্তমানে, আপনি যদি কোনও পাঠ্যবক্সটি কেবলমাত্র সার্ভারের দিক থেকে পঠনযোগ্য হিসাবে সেট করেন তবে আপনি ক্লায়েন্ট রাউন্ডট্রিপের মাধ্যমে তার মানটি পরিবর্তন না করে তার উপর নির্ভর করতে পারেন। ফ্রেমওয়ার্কটিতে ইতিমধ্যে এটি নিশ্চিত করার জন্য পর্যাপ্ত কোড রয়েছে (ভিউস্টেট এনক্রিপশনের মাধ্যমে)। কেবলমাত্র ডেটা পদ্ধতির সাথে, এটি আরও শক্ত হয়ে যায়, কারণ আপনাকে ম্যানুয়ালি সমস্ত কিছু পরীক্ষা করতে হবে। অন্যদিকে, সম্ভবত সুরক্ষা গর্তগুলি স্পট করা সহজ হবে, কারণ আপনার উদ্বেগের জন্য কেবলমাত্র ডেটা থাকবে।
সর্বোপরি, এটি কি আমাদের সমস্যাগুলি সমাধান করবে, বা আরও খারাপ করবে? কেউ কি কখনও এই চেষ্টা করেছে, এবং ফলাফলগুলি কি হয়েছিল? এই ধরণের প্রচেষ্টা (jQuery এবং নৈতিক সমতুল্য একপাশে) সাহায্য করতে পারে এমন কোনও ফ্রেমওয়ার্ক রয়েছে?
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.আপনি এএসপি.এনইটি ঠিক কী তা বর্ণনা করছেন যা আমাকে বলে যে আপনি সম্ভবত এটি সঠিকভাবে ব্যবহার করছেন না। :) আপনার এএসপি.এনইটি অ্যাপ্লিকেশনগুলিতে যদি আপনি আপডেট প্যানেলের মধ্যে উপাদানগুলি রাখেন তবে এএসপি.নেট জাভাস্ক্রিপ্ট লাইব্রেরি সার্ভারের পক্ষ থেকে অ্যাসিনক্রোনাস পোস্টব্যাকগুলি সম্পাদন করবে এবং কেবলমাত্র আপনার নির্দিষ্ট করা উপাদানগুলি পুনরায় রেন্ডার করবে।