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

Bazen, uygulamalarımızın denetleyici kodunda temsil edilen bir iş mantığımız vardır. Bu genellikle modelden çağrılacak yöntemleri ve / veya bunları iletmek için hangi argümanları ayıran mantıktır.

Bunun bir başka örneği, bir dizi iş kuralına göre, modelden döndürülen verileri biçimlendirmek veya sterilize etmek için denetleyicide var olan bir dizi yardımcı işlevdir.

Bu işe yarar, ama felaketle flört edip etmediğini merak ediyorum. Denetleyici ve model arasında paylaşılan iş mantığı varsa, iki katman artık birbirinden ayrılamaz ve kod devralan bir kişi, iş mantığıyla ilgili kodun bulunduğu yerdeki bu düzensizlikle karıştırılabilir.

Benim sorum, denetleyicide ne kadar iş mantığına izin verilmesi gerektiği ve hangi durumlarda varsa?

İdeal olarak hiçbiri

Ama bu her zaman mümkün değil. Size% 20 veya 10 satır gibi sert rakamlar veremem, bu cevaplanamayacağı noktaya özneldir. Tasarım kalıplarını ve onları hafifçe bükmeyi gerektiren durumları nasıl kullandığımı tanımlayabilirim.

Aklımda tamamen bu uygulamanın amacı kalmış. Göndermek için basit bir REST API oluşturmak? Temiz ayrılık veya hatta bir kalıp unutun. Çalışan bir sürümü bir saat içinde çalkalayabilirsiniz. Daha büyük bir şey inşa etmek? Üzerinde çalışmak için muhtemelen en iyisi.

Bireysel olarak içerilen sistemleri inşa etmek amaçtır. İş mantığını yazmaya başlarsanız, bu iki sistemin nasıl etkileşime girdiğine özgü bir sorundur. Daha içine bakmadan bir fikir veremem.

Tasarım kalıpları, bazıları esas ve iyi yazılmış kod temelinde kendilerine sıkı sıkıya uymayı sever. Bir kalıba sıkı sıkıya bağlı kalmanız muhtemelen size kötü bir kod vermez , ancak daha fazla zaman alabilir ve çok daha fazla kod yazmanıza neden olabilir .

Tasarım desenleri, esnek uyacak şekilde ayarlayın senin ihtiyaçlarını. Onları çok fazla bükün ve yine de kırılırlar. Neye ihtiyacınız olduğunu bilin ve ona en yakın tasarım desenini seçin.

Mümkün olduğunca az. Tercihen hiçbiri.

Kontrolör, talebi kabul etmek, isteği işlemek için doğru etki alanı hizmetini istemek ve cevabı doğru görünüme vermekle ilgilenmelidir.

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

Etki alanı nesneleri alan ve bunlardan görünüm modülleri oluşturan bir işlevselliğe sahipseniz, bu durum denetleyiciyle bir arada bulunabilir. Ancak bu sadece ilgili görüşlerin uğruna varolan kod olmalıdır . Veri temizliği ile ilgili işletme düzeyinde bir kural varsa, bunun etki alanı / hizmet seviyenizde bulunması gerekir (uygun ünite testleri ile).

"İş mantığı" terimi kafa karıştırıcı olan bir terimdir, çünkü insanlar bunun ne anlama geldiğiyle ilgili farklı fikirlere sahiptir. Bana göre, "iş mantığı" terimi iki alanı kapsıyor

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

Etki Alanı Mantığı, işletmenizin ilgilendiği 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ırıyor olmanızla ilgili bir mantıktır. Bu CSV ithalat ihracat, sihirbazlar, vb gibi şeyler 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 de tüm uygulama mantığı oraya gitmemelidir. Ancak hiçbir zaman 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 söz ediyordunuz. Biçimlendirme kesinlikle uygulama mantığı olmalıdır. Diğer yandan, sterilize etme verileri etki alanı kurallarına dayanıyorsa, sterilize etme, etki alanı mantığı olabilir. Bu, içeriğe bağlıdır.

Denetleyicilerin etki alanı mantığı üzerinde çok hafif olması gerekir.

Kontrolörler, soyutlanmış bir servis / depo katmanı yoluyla veri deposundan bir kayıt alma ve aynı (veya ilgili) servis tarafından veriyi tekrar veri deposuna aktarma gibi görevleri devretmelidir. Bu işlemler arasındaki mekanik ve ince işler gelince, genellikle denetleyiciden başka bir yere aittir.

Kendimi sık sık kendime veri depolarıma geri yükleyen denetleyicilerime küçük veri sanitasyon yöntemleri ekleyerek buluyorum ve bu etkili bir çözüm olmasına rağmen denetleyicinin amaçlanan rolüne uymuyor. İdeal olarak, modelinizi değiştirecek, doğrulayacak veya ayrıştıracak herhangi bir şey, modelin içinde değilse de çok yakın bir yerde gerçekleşmelidir. Örneğin, bir model nesnesini kaydetmeden önce 'temizlemeniz gerekiyorsa, modelde veya modeli depolamayı kullanan hizmetin bir parçası olarak SanitizeInputs () yöntemini kullanmayı düşünün.

Pragmatik bir bakış açısıyla, modeliniz için iyi bir kalıpla uyumlu bir yaklaşımın olmadığı bir şeyi yapmaya çalışırken, denetleyicinizde mantıkla ya da modelinizde denetleyici davranışını bulduğunuzu gördüm. Doubly, yani 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 görünüp görünmeyeceğini düşünmeye çalışırım, eğer öyleyse, modelde de geçerlidir. Eğer net değilse, bir yerde diğerinden daha "uygun" olup olmadığını düşünmeye çalışıyorum. Genellikle denetleyiciden uzak tutmak için genellikle modele koymayı başaramazsam (daha küçük denetleyiciler ve daha güçlü veri nesneleri için kişisel tercih, YMMV)

Üçüncü bir seçenek, yardımcı program maddelerine ayrı bir yardımcı sınıf olarak atıfta bulunmak olacaktır, ancak bu, birçoğunun görüşüne göre, desene karşı birazdır.

Ayrıca, tam olarak bir modeli takip etmediğiniz için, mutlaka felaketle flört etmeniz gerekmez. Bu projeden önemli miktarda kodun yeniden kullanılmasını gerçekten beklemiyorsanız, projenin kendisiyle tutarlı olması konusunda çok daha fazla endişe duyarım (yani: bir yer seçtikten sonra bu bitleri nereye koyduğunuza dokunma) Bir nedenden ötürü, bir nedenden ötürü projenin ortasının bir bölümünü kurtarmak istediğini tekrar yazmak. Neden ve neden ortak kalıptan saptığınızı ve bu uygulama için beklenen kalıbı tanımladığınızı belgeleyin / yorum yapın.

MVC, yerleşik kalıplardan bir noktada sapma oldu.

Programlamadaki diğer pek çok ilginç kavram gibi, MVC de belirli senaryoları uygulamak için yakın ya da benzer stratejiler ailesine yapı kazandırmak ve odaklanmak için güçlü bir paradigmadır.

Diğer birçok programlama kavramı gibi, MVC de gerçeği basitleştirir, küçük ayrıntıları siler ve izlenecek kaba bir tel kafes modeli sağlar. Gerçekliğin diğer birçok basitleştirmesi gibi, insan aklının gördüğü gibi bir kaosu içine yapıyı getirerek yapar.

Yine de, birçok diğer programlama kavramı gibi, MVS de gerçekliğin basitleştirilmesidir. Mükemmel değil ve tam değil. Bu nedenle, gerçek bir 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üntünün koşullu bir mantık içermesi gerekip gerekmediği?

• Bir modelin doğrudan işletmelerde bulunmayan herhangi bir ek veri içermesi gerekip gerekmediği?

Bunların hepsi, kodu MVC'nin kavramsal fikrine tam ve tam olarak uyacak şekilde ayarlama çabasıyla ortaya çıkan sorulardır.

Sana cevabım denemek değil. MVC yapı sağlar. Uygulamanızı bu vakfın çevresinde oluşturun, ancak mükemmel şekilde oturmasını beklemeyin. Sapmalar olacak, normal. Sadece onları kontrol altında tutmalarını izleyin.