it-swarm.dev

Denetleyici katmanında ne kadar iş mantığının bulunmasına izin verilmelidir?

Bazen uygulamalarımızın denetleyici kodunda temsil edilen bazı iş mantığımız olur. Bu genellikle hangi yöntemlerin çağrılacağını modelden ve/veya hangi argümanların geçeceğinden ayıran mantıktır.

Bunun bir başka örneği, bir iş kurallarına göre modelden döndürülen verileri biçimlendirmek veya sterilize etmek için kullanılabilen denetleyicide bulunan bir dizi yardımcı program işlevidir.

Bu işe yarıyor ama felaketle flört edip etmediğini merak ediyorum. Denetleyici ve model arasında paylaşılan iş mantığı varsa, iki katman artık ayrılamaz ve kodu devralan bir kişi, iş mantığı ile ilgili kodun bulunduğu konumdaki bu eşitsizlik nedeniyle karıştırılabilir.

Sorum, denetleyicide ne kadar iş mantığına izin verilmesi gerektiği ve varsa hangi koşullarda?

41
jellyfishtree

İdeal olarak hiçbiri

Ancak bu her zaman mümkün değildir. Size% 20 veya 10 satır gibi sert sayılar veremem, bu cevaplanamayacağı noktaya özneldir. Tasarım kalıplarını ve onları hafifçe bükmeyi gerektiren koşulları nasıl kullandığımı açıklayabilirim.

Aklımda tamamen uygulamanın amacına kalmış. Basit bir REST api göndermek için? Temiz ayırma veya hatta bir desen unutun. Bir saatten daha kısa bir süre içinde çalışan bir sürümünü çalkalayabilirsiniz. Daha büyük bir şey inşa etmek mi?.

Bireysel olarak kapsanan sistemler oluşturmak hedeftir. İki sistemin nasıl etkileşim kurduğuna özgü bir iş mantığı yazmaya başlarsanız bu bir sorundur. Daha fazla bakmadan bir fikir veremem.

Tasarım kalıpları küflerdir, bazıları temel ve iyi yazılmış kod temelinde kesinlikle bunlara bağlı kalmayı sever. Bir kalıba kesinlikle yapışmak size bad kodu vermeyecektir, ancak daha fazla zaman alabilir ve yazmanıza neden olabilir çok daha fazla kod.

Tasarım kalıpları esnektir, bunları sizin ihtiyaçlara göre ayarlayın. Onları çok fazla bükün ve yine de kırılırlar. İhtiyacınız olanı bilin ve buna en yakın tasarım desenini seçin.

22
Josh K

Mümkün olduğunca az. Tercihen yok.

Denetleyici, isteği kabul etmek, isteği işlemek için doğru etki alanı hizmetinden istemek ve yanıtı doğru görünüme vermekle ilgilenmelidir.

Bu süreçte, tüm "iş mantığı" etki alanı hizmetlerinde bulunmalıdır.

Etki alanı nesnelerini alan ve bunlardan görüntüleme modelleri oluşturan bir işleve sahipseniz, bu durum denetleyiciyle makul bir şekilde bir arada bulunabilir. Ancak bu, ilgili görünümler uğruna yalnızca olan kod olmalıdır. Veri dezenfeksiyonu ile ilgili işletme düzeyinde bir kural varsa, alan/hizmet seviyenizde olmalıdır (uygun birim testleriyle).

10
Eric King

"İş mantığı" terimi, çoğu zaman kafa karıştırıcı olan bir terimdir çünkü insanların bunun ne anlama geldiği hakkında farklı görüşleri vardır. Bana göre, "iş mantığı" terimi iki alanı kapsıyor

  • Alan Mantığı
  • Uygulama Mantığı

Etki Alanı Mantığı, faaliyet gösterdiğiniz temel alanla ilgili bir mantıktır, bu nedenle muhasebeciler için bir başvuru yazıyorsanız, vergi kuralları, defter tutma kuralları vb., Etki alanı mantığının bir parçasıdır.

Uygulama mantığı, bir bilgisayar programı çalıştırmanızla ilgili mantıktır. Bu, CSV içe aktarma dışa aktarma, sihirbazlar vb. Olabilir. Unutulan şifre e-postaları oluşturma gibi şeyler de içerebilir.

Denetleyici katmanına yerleştirebileceğiniz "iş mantığı" türü Uygulama mantığıdır. Belki tüm uygulama mantığı oraya gitmemelidir. Ancak asla etki alanı mantığını denetleyici katmanına yerleştirmemelisiniz. Bu açıkça etki alanı katmanında olmalıdır.

Verileri biçimlendirmek veya sterilize etmek için mantıktan bahsediyordunuz. Biçimlendirme kesinlikle uygulama mantığı olmalıdır. Dezenfekte etme, verilerin dezenfekte edilmesi etki alanı kurallarına dayanıyorsa, dezenfekte etme etki alanı mantığı olabilir. Bu bağlama bağlıdır.

10
Pete

Denetleyiciler etki alanı mantığına çok açık olmalıdır.

Denetleyiciler, soyutlanmış bir hizmet/depo katmanı aracılığıyla veri deposundan kayıt alma ve aynı (veya ilgili) hizmet tarafından veriyi veri deposuna aktarma gibi görevleri devretmelidir. Bu işlemler arasındaki mekanik ve daha ince işlere gelince, genellikle kontrolör dışında bir yere aittirler.

Denetleyicime verileri depoya geri kaydeden küçük veri sanitasyon yöntemleri eklerken kendimi sık sık bulurum ve bu etkili bir çözüm olmasına rağmen, denetleyicinin amaçlanan rolüne iyi uymuyor. İdeal olarak, modelinizi değiştirecek, doğrulayacak veya ayrıştıracak her şey, modelin içinde olmasa da çok yakın olmalıdır. Örneğin, bir model nesnesini saklamadan önce 'temizlemeniz' gerekiyorsa, modelde veya modeli depolamayı işleyen hizmetin bir parçası olarak bir SanitizeInputs () yöntemi kullanmayı düşünün.

4
Nathan Taylor

Pragmatik bir bakış açısından, iyi bir kalıp uyumlu yaklaşım olmayan bir şey yapmaya çalıştığınızda ya kontrol cihazınızda mantık ya da modelinizde kontrolör davranışıyla sonuçlandığını gördüm. Şüphesiz, arkasında büyük bir altyapıya sahip olmayan bir uygulama yazıyorsanız.

Her iki şekilde de gidebilirsiniz, ancak genellikle garip bitin birden fazla denetleyici eyleminde ortaya çıkıp çıkmayacağını düşünmeye çalışırım, eğer öyleyse modele girer. Bu net değilse, bir yerde diğerinden daha "uygun" olup olmadığını düşünmeye çalışıyorum. Genellikle denetleyiciden uzak tutmak için modele koyduğumda başarısız olma (daha küçük denetleyiciler ve daha güçlü veri nesneleri için kişisel tercih, YMMV)

Üçüncü bir seçenek, yardımcı program öğelerine ayrı bir yardımcı sınıf olarak başvurmak olacaktır, ancak bu, çoğunun görüşüne göre bir şekilde desene karşıdır.

Ayrıca, sadece bir paterni tam olarak takip etmediğiniz için, felaketle flört etmek zorunda değilsiniz. Gerçekten bu projeden tekrar kod önemli miktarda yeniden kullanmak beklemediğiniz sürece ben proje kendisiyle tutarlı olması hakkında çok daha fazla endişe ediyorum (yani: bir konum seçtikten sonra bu bitleri nereye koymak flip-flop yok) bazı nedenlerden ötürü projenin ortasının bir kısmını kurtarmak istediğini yeniden yazmaktan ziyade. Nerede ve neden ortak modelden saptığınızı belgeleyin/yorumlayın ve bu uygulama için beklenen modeli tanımlayın.

MVC, bir noktada yerleşmiş kalıplardan bir sapma idi.

4
Bill

Programlamadaki diğer birçok ilginç kavram gibi, MVC de belirli senaryoları uygulamak için yakın veya benzer stratejiler içeren bir aileye yapı ve odaklanma getirmek için güçlü bir paradigmadır.

Diğer birçok programlama konsepti gibi, MVC gerçeği basitleştirir, küçük ayrıntıları atar ve takip etmek için kaba bir tel kafes modeli sağlar. Gerçekliğin diğer birçok basitleştirmesi gibi, yapıyı bir insan zihni tarafından görüldüğü gibi kaosa sürükleyerek işe yarar.

Yine de, diğer birçok programlama kavramı gibi, MVS de gerçekliğin basitleştirilmesidir. Mükemmel değil ve kapsamlı değil. Bu yüzden gerçek dünya senaryosunu basitleştirilmiş bir modele sığdırmak mümkün değildir. Dolayısıyla buna benzer birçok soru ortaya çıkıyor.

  • Bir denetleyiciye ne kadar mantık girmeli?

  • Bir görünümün koşullu mantık içermesi gerekip gerekmediği?

  • Bir modelin, doğrudan tüzel kişiliklerde bulunmayan ek veriler içermesi gerekip gerekmediği?

Bunların hepsi, kodu MVC'nin kavramsal fikrine tam ve tamamen uyacak şekilde ayarlama girişiminde doğan sorulardır.

Sana cevabım, bunu yapmaya çalışma. MVC yapı sağlar. Uygulamanızı bu temel etrafında oluşturun, ancak tam olarak sığmasını beklemeyin. Sapmalar olacak, bu normal. Onları kontrol altında tutmak için izle.

4
user8685