Yanıtlar:
Bir çerçeve değerlendirilirse, sizi bir şeyler yapma yolunda kilitler veya yönlendirir.
Örneğin: bazı insanlar, bir şablon sisteminin, sistemi ham HTML döndürmeye açık bıraktığı için kullanıcı tanımlı yöntemlere ve işlevlere erişim sağlamaması gerektiğine inanmaktadır. Dolayısıyla, düşünülmüş bir çerçeve geliştiricisi yalnızca veri yapılarına erişime izin verir. Tasarım gereği, yazılım sınırlayıcıdır ve tasarımcıyı işleri kendi başına yapmaya teşvik eder.
Başka bir örnek ( sinyaller bağlantısından alınmıştır ) wiki örneğidir . Wiki tasarımcılarının birçok fikri vardı. HTML'nin insanların yazmak için çok karmaşık olduğunu düşündüler, bu nedenle içeriği güncellemenin daha doğal bir yolu olduğunu düşündükleri şeyle karşılaştılar. Ayrıca süslü tasarımı da çıkardılar çünkü odaklanmanın içerikten ziyade tasarımdan daha fazla olması gerektiğini hissettiler.
Apple ürünlerini tasarlarken güçlü fikirlere sahiptir.
Düşüncesiz yazılım tasarımı daha çok PERL / PHP gibidir. Geliştiriciye izin verir ve geliştiriciye doğru kararları verir ve ellerinde daha fazla kontrol sağlar.
Microsoft'u düşünülmemiş sütuna da yerleştiririm. Bir Microsoft çerçevesi iyi bir örnek un-opininated: .NET. CLR ve teknik özellikleri açarak, onu her türlü dile ve uygulama stiline açtı.
Görüşlü yazılım, temelde bir şey yapmanın tek yolu ( doğru yol ™) olduğu ve bunu farklı bir şekilde yapmaya çalışmanın zor ve sinir bozucu olacağı anlamına gelir. Öte yandan, doğru şekilde yapmak ™ ™, vermeniz gereken kararların sayısı azaldıkça ve yazılım tasarımcılarının yazılımı çalıştırmaya konsantre olma yeteneği arttıkça yazılımla geliştirmeyi çok kolaylaştırabilir. Eğer iyi bir şekilde yapılırsa, probleminiz çözüme güzel bir şekilde eşlenirse, görüşlü yazılım kullanmak harika olabilir. Sorununuzun sağlanan araçlarla eşleşmeyen kısımlarını çözmek gerçek bir acı olabilir. Burada bir örnek Ruby on Rails olabilir.
Diğer yandan, düşüncesiz yazılımlar kullanıcıya (geliştiriciye) çok fazla esneklik katar. Bir sorunu çözmenin bir yöntemini yasaklamaz, ancak sorunu birçok şekilde çözmek için kullanılabilecek esnek araçlar sağlar. Bunun dezavantajı, aletler çok esnek olduğu için herhangi bir çözüm geliştirmek nispeten zor olabilir. Çözümün çok daha fazlasının kullanıcı (geliştirici) tarafından elle kodlanması gerekebilir, çünkü çerçeve yeterli yardım sağlamaz. Ayrıca bir çözümün nasıl sağlanacağı hakkında çok daha fazla düşünmelisiniz ve vasat geliştiriciler, bazı düşünülmüş yazılımlardan satın aldıklarından daha kötü çözümlerle sonuçlanabilir. PERL muhtemelen düşünülmeyen yazılımların klasik örneğidir.
Benim idealim görüşülmemiş bir çerçeve, ancak güçlü sözleşmeleri olan bir çerçevedir. ASP.NET MVC bu kategoriye koymak istiyorum. Gerçekte, tüm yazılımlar bir dereceye kadar değerlendirilir (belki de PERL olmasa da). MVC, model seçiminde güçlü sözleşmelere sahiptir, ancak bu sözleşmelerdeki sorunları çözmek için birçok farklı yol sunar. Bu yollardan bazıları modeli bile bozabilir. Bununla birlikte, doğru bir şekilde kullanılması, böyle bir çerçevede gelişen sözleşmelere uygun olarak gerçek bir zevk olabilir.
Temel olarak, herkesi memnun etmek yerine yazarlarının çalışması gerektiğini düşündüğü şekilde çalışan bir yazılımdır. Bu, birçok insanın hoşuna gitmeyeceği, ancak sevdiklerinin seveceği anlamına gelir.
Raylar muhtemelen tartışmalı bir çerçevenin kanonik örneğidir: işleri kendi yollarıyla yaparsınız ve her şey pürüzsüzdür. Eğer yapmazsan, biraz acı içindesin. Ama sorun değil - bir şeyleri kendi yolunda yapmak istemiyorsanız, Rails kullanmak istemezsiniz.
Denge adına, görüşlü yaklaşıma (diğer cevapların bazılarının aksine) daha elverişli (daha çok görüşlü) bir açıklama sunacağım.
Görüşlü çerçeveler, çoğu insan ve çoğu senaryo (yazarların gözünde) için en iyi uygulama olması gereken bir "altın yol" sağlar.
Ancak bu mutlaka kilitlenme anlamına gelmez. Bu, işleri farklı şekilde yapmak için ekstra çaba gerektirebileceği anlamına gelir.
Daha az görüşlü çerçeveler bir dizi farklı seçenek sunar ve karar vermek için size bırakır.
Görüşlü çerçeveler genellikle tekerleği yeniden icat etmek veya aynı sorunu tekrar tekrar düşünmek ve böylece mevcut gerçek probleme odaklanmaya yardımcı olmak için yükü geliştiriciden kaldırır.
Açık kaynak dünyasında, birçok fikirli ancak rakip çerçeveyi bulabilirsiniz, bu yüzden hala bir seçeneğiniz vardır. Sadece kendi altın yolunu seçmelisin.
Görüşlü yazılım, işleri belirli bir şekilde yapmayı kolaylaştıracak şekilde tasarlanmış ve tasarlanmıştır. Bazı tasarım modellerini diğerlerinden daha fazla tercih eder. Bu süreçte, geliştirildiği yazılım geliştirme tarzından sapmayı zorlaştırır. Bunu ifade etmenin bir başka yolu da "Konfigürasyon üzerine Sözleşme" yi desteklemesidir. yani, yazılım birçok yapılandırma yönünü üstlendiğinden yapılandırma seçenekleri oldukça sınırlıdır. Varsayımların anlaşılmasından sonra, görüşlü yazılımların ustalaşması genellikle daha hızlıdır.
Öte yandan, açılmamış yazılım az sayıda varsayım yapar. Sonuç olarak, açılmamış yazılımlar / yazılım geliştirme çerçeveleri genellikle birçok yapılandırma seçeneğine sahiptir. Bir geliştirici genellikle yazılımın çeşitli yönleriyle ilgili birçok karar vermelidir. Genellikle, bu muazzam seçeneklerle başa çıkmayı kolaylaştıracak çeşitli araçlar geliştirilir. .NET için Visual Studio .NET, Java için Eclipse IDE vb. Kullanılmayan yazılımın ustalaşması genellikle düşünülen yazılımdan daha uzun sürer.
tl; dr :
Bir çok insan ASP.NET MVC'yi "açılmamış" bir çerçeve olarak atıfta bulunuyor ve ben de bununla ilgili birkaç düşünce ile tartmak istedim.
ASP.NET MVC'nin çok fazla yetki vermediği doğrudur; Linq-to-SQL, ADO.NET Entities, NHibernate, vs. gibi istediğiniz kalıcı çözümü kullanabilirsiniz.
Kapak tarafında, MVC çerçevesi, denetleyicileri, görünümleri, modelleri ve diğer kodları bulmak için önceden tanımlanmış kalıbı takip etmeyi şiddetle öneren Phil Haack'i alıntılamak için "konfigürasyon üzerinde konvansiyonu" tercih etme eğilimindedir. Bu davranışı değiştirebilmenize rağmen, akımla yüzmek daha kolaydır ve çoğu insan için bunu yapmakta sorun yoktur.
Ayrıca ASP.NET MVC'yi çevreleyen çok sayıda görüşlü insan var, bu da örtü, örneğin birim testi ve bağımlılık enjeksiyonu; Ben iyi bir test ve endişelerin ayrılması için çalışıyorum, ancak bu tür konuların boğazından biraz aşağıya doğru itildiğini ve genellikle daha kullanışlı temelleri kapsamadan önce olduğunu düşünüyorum.
Yine, bu alanlarda, çerçevenin kendisinin, istediğiniz birim test çözümünü ve kullanmak istediğiniz bağımlılık enjeksiyonunu ve alaycı çerçevelerini benimsemeye tamamen açık olduğuna karar vermeliyim, bu yüzden başka bir örnek esneklik, hatta "İncil dayak" birim test, vb oluyor gibi görünüyor.
Bir çerçevede uygulanan konvansiyon miktarı ve alınan karar sayısıdır.
Örneğin, form verilerini bir denetleyici eylemine göndermenin 5 (veya daha fazla) farklı yolu varsa (ASP.NET MVC'de olduğu gibi), çerçeve oldukça "görüşsüz" gibi görünüyor - karar verilmiş sana!
Bununla birlikte, çerçeve (doğrudan başka yollardan devre dışı bırakarak veya güçlü bir şekilde teşvik ederek) bu şeyi yapmanın yalnızca bir yolunu (Fubu MVC'de olduğu gibi) etkinleştirirse, kararın çerçeve tarafından alındığını söyleyebilirsiniz. böylece çerçeveyi görüşlü kılar.
Şu anda çok şey göreceğiniz örnek ASP.NET MVC çerçevesidir. Şaşırtıcı bir şekilde genişletilebilir, ancak bu bazı açılardan düşüşüdür, et yoktur. Veri erişimi yapmak ister misiniz? Bunu kendin yazman gerekecek. AJAX'ın devam etmesini ister misiniz? Aynen.
Bununla birlikte, oldukça genişletilebilir olduğu için, üzerine inşa ederseniz bunu tartışmalı bir çerçeveye dönüştürebilirsiniz. Bu gibiler ne MVCContrib yapmak, onlar daha az kod yazmak zorunda anlamına gelir size şeyler yapmanın özel yöntemler verir.
Bu, görüşten kopmak istiyorsanız, vanilya sürümü üzerinde çalıştığınızdan daha fazla iş yapılması anlamına gelir. Bu bir 80/20 senaryosudur. Eğer fikirli çerçevenizi doğru seçtiyseniz, sadece zamanın% 20'sinden gelen görüşlerden kopmak isteyeceksiniz ve zamanın% 80'inde oldukça üretken olacaksınız.