ওয়েব ফ্রেমওয়ার্ক ব্যবহার করে যে সুবিধা ও অসুবিধাগুলি থাকতে হয়েছিল? [বন্ধ]


16

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

সুবিধাদি:

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

অসুবিধা:

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

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

উত্তর:


12

নীচের লাইনটি এখানে: ফ্রেমওয়ার্ক কনফিগারেশনের বাইরে বৈশিষ্ট্যগুলি প্রয়োগ করা কঠিন হতে পারে।

আসুন অনুমানের মাধ্যমে এই অনুমানের মধ্য দিয়ে যাই।

হারানো বোঝাপড়া - কোনও ফ্রেমওয়ার্কের বৈশিষ্ট্যগুলির উপর নির্ভর করে একজন বিকাশকারী কীভাবে জিনিসগুলি (ফণার নীচে) কাজ করে সে সম্পর্কে বোঝাপড়া হারাতে পারে।

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

বিশ্বাস করুন বা না করুন, আপনি ফ্রেমওয়ার্কটি ব্যবহার করে ভুল করবেন। আপনি কী ভুল করেছেন তা বুঝতে আপনাকে সরাসরি HTTP এর সর্বনিম্ন স্তরে ডিবাগ করতে হবে।

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

কনফিগারেশন ক্লিফ - আপনার কাঠামোর কনফিগারেশনের চেয়ে একবারে আপনার উত্পাদনক্ষমতা হ্রাস পাওয়ার পরে ফ্রেমওয়ার্ক কনফিগারেশনের বাইরের বৈশিষ্ট্যগুলি প্রয়োগ করা কঠিন হতে পারে।

এটি মূল্যবান সামান্য জ্ঞান তোলে।

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

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

বিকাশকারী ট্রামিলাইনস - আপনাকে (বিকাশকারীকে) জিনিসগুলি সেইভাবে করতে হবে যেভাবে [ফ্রেমওয়ার্ক] বিকাশকারী আপনি জিনিসগুলি করতে চান।

সঠিক। এবং এটি প্রায়শই ভাল জিনিস। জিনিসগুলিকে একটি সামঞ্জস্যপূর্ণ উপায়ে করা নিজের ব্যক্তিগত পছন্দ মতো করার চেয়ে মূল্যবান। এর জন্য "শেখার" এবং "বোঝার" প্রয়োজন হতে পারে তবে এর মূল্য রয়েছে।

সুরক্ষা সমস্যা - দ্রুত পেশাদার পেশাদার ওয়েবসাইট বিকাশের জন্য এই সরঞ্জামগুলি দেওয়া একটি সম্ভাব্য ঝুঁকি, লোকেরা প্রতারণামূলক সংস্থাগুলির জন্য পেশাদার পেশাদার ওয়েবসাইটগুলি দ্রুত তৈরি করতে পারে।

কি? কাঠামোর সাথে এর কোনও যোগসূত্র নেই। প্রতারণা হ'ল প্রতারণা, ব্যবহৃত সরঞ্জাম নির্বিশেষে।


3
আমি "হারানো বোঝাপড়া" সম্পর্কিত আপনার সাথে একমত নই। আপনি যদি জিকুয়েরিকে উদাহরণ হিসাবে গ্রহণ করেন তবে স্ট্যাক ওভারফ্লোতে আপনার কয়েক ডজন প্রশ্ন তাকানো দরকার যেখানে এটি স্পষ্ট।
RoToRa

5
@ রোটোআরআ: যদি আপনি এসও (যেমন, সি প্রোগ্রামিং) এর কোনও নির্দিষ্ট বিষয়ের দিকে নজর দেন তবে আপনি বিপুল সংখ্যক লোক দেখতে পাবেন যা ঘটছে তা অনুধাবন করতে পারে না। আসলে, কিছু লোক এমনকি ভাসমান-পয়েন্ট সংখ্যাটি কী তা বুঝতে পারে না। আমি মনে করি না এটি কাঠামো। আমি মনে করি এমন কিছু লোক রয়েছেন যাদের প্রযুক্তি বোঝার সীমিত ক্ষমতা রয়েছে have
এস .লট

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

@ জে হারলি 1: "তবে এটি বিষয় থেকে কয়েক মাইল দূরে ছিল"। এটি ঠিক করতে আপনি প্রশ্নটি আপডেট করতে পারেন।
এস .লট

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

3

কন: পরিণামের সম্ভাব্য সম্ভাবনা হ্রাস / জনপ্রিয়তা হ্রাস

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

প্রো: ব্যবসায়ের জন্য কোড

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

চিয়ার্স রায়ান, এখানে কিছু ভাল পয়েন্ট রয়েছে। আমি কখনই ফ্রেমওয়ার্কটিকে গ্রেট থেকে বাদ / পড়ার বিষয়টি বিবেচনা করি নি।
JHarley1

দয়া করে দয়া করে ডাউনটাতে কিছু প্রতিক্রিয়া পেতে পারি?
রায়ান হেইস

আমি এটি দরকারী বলে মনে করেছি - আমি ভোট দিয়েছি।
JHarley1

3

সুবিধাদি

  • দ্রুত বিকাশের সময়
  • কম বাগ
  • দ্রুত ভাগ করে নেওয়া বিকাশ
  • লাইব্রেরি সমর্থন
  • ইজি ডিবি ইন্টারঅ্যাকশন

অসুবিধেও

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

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


2

মাথায় আসা দুটি জিনিস হ'ল ...

সুবিধাদি

  • কোড পুনরায় ব্যবহার - একটি ফ্রেমওয়ার্ক ব্যবহার করে আপনি পরীক্ষিত এবং সত্য যে কোডটি পুনরায় ব্যবহার করছেন।
  • দ্রুত বিকাশ / প্রোটোটাইপিং।
  • (প্রায়শই) সমন্বিত ইনপুট বৈধতা যা নিরাপদ বলে ধরে নেওয়া যেতে পারে (প্রদত্ত বিকাশকারী এটি সঠিকভাবে ব্যবহার করছে)

অসুবিধেও

  • সমর্থন হারাতে হবে। এখানে মাথায় আসা সিমফনি 1.4। আমি ভেবেছি সিমফনি বেশ কিছু সময়ের জন্য ১.৪ সমর্থন করবে, কিন্তু ২.০ পিছনের দিক থেকে সামঞ্জস্যপূর্ণ নয় তা জেনেও, ১.৪ আসন্ন বছরগুলিতে সমর্থন হিসাবে মনে হচ্ছে।
  • ওভারহেড; একটি ফ্রেমওয়ার্ক ব্যবহার করে আপনি এমন হাজার হাজার লাইন চালাচ্ছেন যা আপনার নির্দিষ্ট প্রয়োগের ক্ষেত্রে প্রযোজ্য নাও হতে পারে, তবে অন্যদের জন্য প্রযোজ্য। কেউ কেউ এটিকে যুক্তিসঙ্গত বাণিজ্য বন্ধ বলে মনে করেন এবং কেউ কেউ পারফরম্যান্সের জন্য তাদের কোডটি গ্রাউন্ড থেকে লিখতে পছন্দ করেন।
  • আপনার নির্দিষ্ট প্রয়োজনের জন্য ভুল কাঠামো ব্যবহার করা। সমস্ত ফ্রেমওয়ার্ক সমানভাবে তৈরি হয় না।

1

এটি আপনার ব্যবহৃত কাঠামোর উপর নির্ভর করে।

আপনি ASP.NET ব্যবহার করেন, তাহলে আপনি একটি অসুবিধা করছি: এটি একটি ছিদ্রময় বিমূর্ততা এর শ্রেষ্ঠ সময়ে , এবং নাহয় এটা কিছু আছে যা অন্য অবকাঠামো মধ্যে তুচ্ছ আছে সত্য যে তুমি লুকিয়ে না করতে ব্যাথা তোলে ওয়েবে কাজ করা।

এএসপি.নেট এমভিসি সেই সমস্যাটি সমাধান করার চেষ্টা করে এবং এটি খুব ভালভাবে সম্পাদন করে।

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


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

1

আমি কিছু পয়েন্ট যোগ করতে চাই।

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

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

সুবিধাদি:

  • যখন আপনি ধারাবাহিকভাবে ফ্রেমওয়ার্কগুলি ব্যবহার করেন তাদের প্রকল্পগুলির জন্য শিক্ষার সময় হ্রাস পায় যারা ইতিমধ্যে আপনার প্রকল্পগুলিতে কাজ করেছেন।
  • আপনার নিজস্ব দ্রুত বিকাশ
  • আপনার নিজস্ব ক্ষমতাবান বিকাশকারী

@ কিদিজক: আমি লাইসেন্সিংয়ের মাধ্যমে কখনও পাইনি, ফ্রেমওয়ার্কের জন্য অর্থ প্রদানের কোনও উদাহরণ আছে কি?
JHarley1

@ JHarley1 oakleafsd.com আমি জানি না যে আমি এটিকে "ওয়েব ফ্রেমওয়ার্ক" বলব কিন্তু মেরে মর্টালস। ওয়েব অ্যাপ্লিকেশনগুলি দ্রুত তৈরি করতে আপনাকে সাহায্য করার জন্য নেটওর এক্সটেনশন রয়েছে। যদিও নেট ফ্রেমওয়ার্ক নিজেই এখন এই ফ্রেমওয়ার্কটি বেশিরভাগই অচল করে দিচ্ছে।
রায়ান হেইস

@ জারলে আমি আমার উত্তরে কিছুটা সাধারণীকরণ করতে পারি, তবে মনে মনে আমি টেলিরিক ওয়েবকন্ট্রোল বা পুনরুত্থান পুনর্গঠন < / i> </ i> /index.php এর মতো জিনিসগুলি নিয়ে ভাবছিলাম । আমিও একটি কোম্পানী যেখানে ExtJs পরিবর্তন লাইসেন্সিং সময় একটি সমস্যা হয়েছে এ কাজ sencha.com/forum/showthread.php?33096-License-Change
KeesDijk

-2

আমি গত 13 বছরে ব্যক্তিগত অভিজ্ঞতা থেকে কথা বলি। আমার সংস্থায় আমরা স্ট্রুট ব্যবহার করতাম, একটি স্বল্প বক্ররেখার পরে এটি দুর্দান্ত ছিল। আমার পরবর্তীটিতে আমরা একটি আর্কিটেকচার ব্যবহার করলাম যা বেশিরভাগই অস্বচ্ছ ছিল, কিছুটা স্ট্রट्स পছন্দ হলেও বেড়ে ওঠে, আমরা এটি প্রসারিত করতে পারি তবে মূল কোডটি কেবল জার ছিল। ইত্যাদি। গত 3 বছরে একটি ছোট সংস্থায় কাজ করা হয়েছে (দেবের সংখ্যা <30) এবং এটি ছিল আমাদের নিজস্ব জেএসপিএস, সার্লেটলেট এবং ইজবিএস। আমাদের একাধিক ক্লায়েন্ট এবং jsps এর পুনরাবৃত্তি তাকান, 2012 সালে একটি j2ee ফিল্টার তৈরি করা হয়েছিল যা 20% struts2 নকল করে। স্টুট 2 ব্যবহার করবেন না কেন? আমাদের ইচ্ছা থাকলেও: এটি আমাদের প্রধান স্থপতি পাস করতে পারিনি; পর্যাপ্ত অভিজ্ঞতা বা সময় নয়।

সুতরাং আমাদের কিছু সাধারণ জেএসপিএস ছিল যা আমাদের মিনি ফ্রেমওয়ার্ক ব্যবহার করেছিল inter এখন যখন আমার কাছে একটি স্ট্রুট 2 বইয়ের মধ্য দিয়ে যাওয়ার সময় হয়েছে আমি দেখতে পাচ্ছি যে আমরা এতটা মিস করেছি!

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

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