Neden herkes denetleyicileri bir klasöre, görünümlerini bir başkasına koyuyor?

Asp'den ve bir mvc çerçevesine, asp.net mvc'ye veya nancy'ye bürünmeye hazırlanıyorum. Nereye gidersem gideyim, kontrolörler / modüller için klasörler ve görünümler için klasörler görüyorum. Bu sadece şeyleri türüne göre bir kenara atma ile ilgili bir Pavlovian refleksi mi, yoksa daha derin bir bilgelik çalışması var mı? Birlikte açmam muhtemel dosyaları bir arada sakladığım, kayda değer bir rahatlık olan küçük bir konsept kanıt projem var. Bu dosyalar da birbirlerini arayabileceklerinden, daha kısa, daha az kırılgan, göreceli bağlantılarla yapabilirler. Bu desen mvc tarafından zorlanır, çünkü klasör yolu artık otomatik olarak url yoluna karşılık gelmez ve asp.net mvc'de proje şablonları ve yönlendirme, views \ controllers \ schism öğesini zorlar.

Bu microsoft page , alan kavramını tanıtır. Bu yapay ayrılıktan dolayı hantalca büyük uygulamaların nasıl gerçekleştiğinin bir kabulü olarak okunabilir.

İnsanlar “kaygıların ayrışmasına” itiraz edeceklerdir, ancak kaygıların ayrılması ayrı kaynak dosyalara sahip olmakla zaten başarılmıştır. Somut bir kazanç yok, öyle görünüyor ki, sıkı sıkıya bağlı olan bu kaynak dosyaları alıp bunları klasör yapısının karşıt uçlarına göndermekten?

Bununla savaşan başka biri var mı? Herhangi bir ipucu?

Kargo kültü programlama olduğunu söylemek isterim , ancak bu yapının teknik nedenleri var. Asp.Net MVC neredeyse her şey için konfigürasyon yaklaşımı üzerine bir anlaşma yaptı. Varsayılan olarak, Razor görünüm motoru, Viewshangi görünümün denetleyiciden döneceğini çözmek için dizinde arama yapar . Bununla birlikte, farklı bir proje yapısı elde etmek için birkaç kırılma vardır ve Microsoft daha akıllıca bir proje yapısı oluşturmamıza izin vermek için Alanlar adlı bir MVC özelliği sunar . Görünümlerin nereye bakılacağını belirtmek için kendi görünüm motorunuzu da uygulayabilirsiniz .

Neden kargo kültü programlaması olduğunu ve bu konuda haklı olduğunuzu söylüyorum? Bob Amca, beni projenin dizin yapısının bir MVC uygulaması olduğunu söylememesi gerektiği konusunda ikna etti . Bana bunun bir dükkan cephesi veya bir zaman aşımına uğrayan istek sistemi veya başka bir şey olduğunu söylemelidir. Üst düzey yapısı ve mimarisi hakkında bize gereken şey bu şey, değil nasıl o hayata geçirildi.

Kısacası, bu konuda haklı olduğuna inanıyorum, ancak herhangi bir diğer dizin yapısı çerçeveye karşı savaşacak ve Asp.Net MVC çerçevesini bir şeyler yapmayı denemek istemediğinizi söylerken bana güvenecekti. yapmak için tasarlanmadı. Gerçekten daha yapılandırılabilir olması üzücü.

Mimari kaygıları hızla çözmek için, işletme modellerinin (iş değil, görünüm) ve DAL'nin MVC uygulamanızdan çağrılan ayrı bir proje / kütüphanede yaşaması gerektiğine inanıyorum.

Sadece kontrolörün görünümü ile çok sıkı bir şekilde bağlantılı olması ve muhtemelen birlikte değiştirilmesi muhtemeldir. Bağımlılık yoluyla bağlanma ve mantıksal bağlanma arasındaki farkı hatırlamak hepimizde akıllıcadır. Kodun bağımlılıklarının çözülmüş olması, mantıksal olarak daha az eşleştirilemez.

Sebep ne olursa olsun, bu kötü bir uygulamadır. Çok OO karşıtıdır, çünkü paketler veya klasörler (ne çağırmak istersen), zayıf bağımlılıklara sahip olmalıdır. İçlerindeki sınıflar (veya dosyalar) güçlü bağımlılıklara sahip olmalıdır.

Tüm görünümleri bir klasöre ve tüm kontrol cihazlarını başka bir klasöre atarak, çok çok sıkı bağlantıya sahip iki paket yaratıyorsunuz. Bu, paketler arası bağımlılıkların zayıf olması ilkesine aykırıdır.

Bir görünüm ve bir kontrolör bir bütünün iki yarısıdır ve birbirlerine ait olmalıdır. Sol taraf çoraplar için bir dolabınız ve sağ taraf çoraplar için bir dolabınız olmazdı.

'Neden herkes ...?' Soru: İşte bazı potansiyel sebepler, gerçekte sübjektif bir soru olduğundan, bunların hangi kombinasyonun gerçek bir sebep olduğunu tam olarak bilmiyorum.

• Mantıksal mimariyi (model, görünüm, denetleyici) eşleşen bir klasör ve ad alanı yapısıyla çoğaltmak için

• ASP.net MVC proje şablonunu takip etme konvansiyonu ve uygunluğu

• Ad alanına göre gruplamak için, Controllers/klasör bir .Controllersad alanına yol açacağından

• Olabilir DI / IoC bazı senaryolara olanak nerede kontrolör sınıfları sadece Sorgulanan / taranmış 'Kontrolörleri' ile biter-/ içeren bir ad alanından (bu yanlış olabilir)

• T4 şablonlarının modelleri ve denetleyicileri taramasını ve iskeletlemesini sağlamak için görünümler oluşturmak için

Projenizi mantıklı kılıyorsa, her zaman kendi konvansiyonunuzu oluşturabilir ve uygulayabilirsiniz; Ancak, eğer büyük bir projede ve / veya büyük bir ekipte çalışıyorsanız, herkesin bildiği varsayılan konvansiyonun daha iyi bir seçim olabileceğini unutmayın (mutlaka doğru olanı değil!).

Sözleşmenizin izlenmesi daha kolay ve üretkenliği engellemiyorsa, elbette yapın! ve hatta geliştirici topluluğu ile sosyalleşmek ve geri bildirim almak için bir ya da iki blog yazısı yazabilirsiniz.

Görüş ve denetleyicileri ayrı dizinlerde tutmanın bir nedeni, bir proje üzerinde çalışan ön uç ve arka uç geliştiricilere sahip olmanızdır. Ön uç geliştiricilerin arka uç koda erişmelerini önleyebilirsiniz (örneğin, PCI uyumluluğuna yardımcı olmak, hassas koda erişimi olanları kısıtlamak).

Diğer bir sebep de, "temaların" kullanımını kolaylaştırmak ve görünüm yolunda küçük bir değişiklik yaparak tüm şablonları değiştirmek.

Üçüncü bir sebep, MVC çerçevesindeki görünümleri belirtirken basit bir dizin düzenine sahip olmaktır. Her görünüme büyük uzun bir yol yerine alt dizini ve dosyayı belirtmek daha kolaydır.

Tek "sıkı bağlantı":

1. Değişkenler denetleyici tarafından görünüme gönderilir.
2. Görünümdeki form alanları veya eylemler, denetleyiciye geri gönderilir.

Genel denetleyici kullanıyorum ve değişken isimlerini görünümde genel tutmaya çalışıyorum, böylece birçok görünüm aynı denetleyiciyi kullanabiliyor ve çoğu denetleyici aynı görünümü kullanabiliyor. Bu nedenle görüşlerini tamamen ayrı tutmayı tercih ediyorum. Model, uygulamanızdaki her "şeyi" ayırt edebildiğiniz yerdir - bu özelliklere erişmek / bunları değiştirmek için bir özellik listesi ve yöntemi olan nesneler olabilir.

Sıkı birleştirilmiş kod için, sizin için işe yarayabilecek bir yaklaşım, bir paketin veya "modülün" parçası olan tüm dosyaları ad alanlı bir dizinde bir arada tutmaktır. Ardından, ham şablonlarınızı ana "görünümler" dizinine kopyalamak veya "derlemek" için bir komut dosyası kullanabilirsiniz. Örneğin:

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

Ne yazık ki, mevcut bir temanın yapısını değiştirmek isterseniz, görünümleri güncellemek için paket dizinlerinin içinde ve dışında daha fazla dokuma vardır.

Görünümlerin, json, xml, csv veya html olsun, verileri biçimlendirmenin bir yolu olduğunu düşünün. Bu, özellikle uygulamanızın bir API olarak çalışmasını istiyorsanız da yardımcı olur. Genel değişken adlarını kullanarak görünümü verilerden ayırmaya çalışın, böylece aynı şablonu birçok denetleyici veya model için kullanabilirsiniz (ya da sürdürmeniz gereken kod miktarını en aza indirmek için içerir).

Bunu mutlaka herkes yapmaz. Örneğin, python'un Django çerçevesi, uygulamanızın alt modüllerinin kendi modelleri ve görünümleri ve şablonları ile kendi dizinlerinde yaşadığı bir uygulama kavramına sahiptir (görünümler esasen Django'nun denetleyicileri dediği şeydir). Bu tür şeyleri yapmayı tercih ediyorum çünkü bu, bir "uygulamayı" kolayca paketleyebileceğim ve projelerimdeki uygulamalar listesine ekleyerek projeler arasında yeniden kullanabileceğim anlamına geliyor. Farklı parçaların nerede olduğunu bulmak da daha kolay. Urls.py dosyasına bakar ve bir şey görürsem url(r'^users/', include('my_site.users.urls')), modülün my_site.userskullanıcıları yöneten tüm kodu içerdiğini biliyorum . Modüllere bakmayı my_site.users.viewsve my_site.users.modelsne zaman kullanıcıların nasıl yaratıldığını ve doğrulandığını görmek istediğimi biliyorum . Tüm rotalarımın içinde tanımlandığını biliyorum my_site.users.url.

Ayrıca eğer yeterince genelse, muhtemelen bu modülü değiştirerek veya bir kütüphane olarak paketleyip OSS olarak yayınlayarak bu siteyi diğer sitelerde de kullanabilirim.

Unutmayın ki , denetleyicileri ve görünümleri farklı klasörlerde tutmanın Microsoft tarafından önerilen yolu , bu nedenle çoğu önerilen yapıyı izler.

1. Bunun bir nedeni, denetleyicilerin her zaman görüşlerle birebir ilişkisi olmamasıdır, özellikle kısmi görüşler denetleyiciler arasında paylaşılabilir.
2. Projeniz büyüdüğünde başka bir sebep olabilir; denetleyicileri ve ünite testlerini başka bir projeye çekmek isteyebilirsiniz, ancak görünümler için aynı şeyi yapmak zordur.

Gibi Senin yöntemini yapmakla ilgili birçok mesaj vardır söyledikten bu .

Kayıt için

Neden kargo kültü programlaması olduğunu ve bu konuda haklı olduğunuzu söylüyorum? Bob Amca, beni projenin dizin yapısının bir MVC uygulaması olduğunu söylememesi gerektiği konusunda ikna etti. Bana bunun bir dükkan cephesi veya bir zaman aşımına uğrayan istek sistemi veya başka bir şey olduğunu söylemelidir. Üst düzey yapı ve mimarlık bize bunun ne olduğu hakkında değil, nasıl uygulandığından bahsetmemelidir.

Soru: Koda kim erişebilir? Programcılar. Son kullanıcılar kodu önemsiyor mu? Hayır. Ve bir programcının yaptığı gibi kod. Veya daha spesifik olarak, türlere dayalı sınıflar (kontrolörler, servis, model vb.). Bu nedenle, mantıklıdır ve kodun davranışını yerine kodun türünü temel alan bir kod bulabilirseniz, bir kodun hatalarını ayıklamak kolaydır. Artı, diyelim ki bir takım proje, biri denetleyiciden sorumlu, diğeri modelden, diğeri diğeri görünümden bir diğeri. Projeyi parçalara ayırmak kolaydır. İyi bir kod, bir sözdizimi şeker kodunu değil, hata ayıklaması kolay bir koddur. Bob Amca yine yanlış.

Projenin davranışını taklit etmeye çalışmak (mağaza önü) kargo kültüdür.