Kalın modeller Vs. İş Mantığı, Ayrımı nerede çiziyorsunuz?

Bugün kuruluşumdaki başka bir geliştirici ile eşlenen sınıfların veritabanına nerede ve nasıl yöntem ekleneceği konusunda hararetli bir tartışmaya girdim. Kullanıyoruz sqlalchemyve veritabanı modellerimizdeki mevcut kod tabanının büyük bir kısmı, bir sınıf adı, veritabanı tablolarından python nesnelerine neredeyse mekanik bir çeviri ile eşleştirilmiş özelliklerin bir torbasından biraz daha fazlası.

Argümanda, konumum ORM kullanmanın birincil değerinin, eşlenen sınıflara düşük düzeyli davranışlar ve algoritmalar ekleyebilmenizdi. Modeller önce sınıflardır ve ikincil olarak kalıcıdırlar (bir dosya sisteminde xml kullanarak kalıcı olabilirler, ilgilenmeniz gerekmez). Onun görüşü, herhangi bir davranışın "iş mantığı" olması ve zorunlu olarak sadece veritabanı kalıcılığı için kullanılacak kalıcı modelde herhangi bir yere ait olmasıdır.

İş mantığının ne olduğu ve ayrılması gerektiği arasında kesinlikle bir ayrım olduğunu düşünüyorum , çünkü bunun nasıl uygulandığının alt seviyesinden bir izolasyonu var ve model sınıflarının sağladığı soyutlamanın olduğuna inanıyorum etki alanı mantığı önceki paragrafta tartıştım, ama parmağımı bunun ne olduğuna koymakta zorlanıyorum. Ben API ne olabilir (bizim durumumuzda, HTTP "ReSTful" olan) daha iyi bir duygusu var, kullanıcıların API yapmak istediklerini, ne yapmak için izin verilir ve nasıl farklı çağırmak yapılır.

tl; dr: Bir ORM kullanırken eşlenmiş bir sınıftaki bir yönteme ne tür şeyler girebilir veya gitmelidir ve başka bir soyutlama katmanında yaşamak için nelerin dışarıda bırakılması gerekir?

Çoğunlukla seninleyim; iş arkadaşınız ya anemik etki alanı modeli antipatternini ya da modeli belirgin bir faydası olmayan bir "kalıcılık modeli" içinde çoğaltmak için tartışıyor gibi görünüyor (bunun yapıldığı bir Java projesi üzerinde çalışıyorum ve bu büyük bir sürdürülebilirlik baş ağrısı, modelde herhangi bir değişiklik olduğunda işin üç katı anlamına gelir).

Bir ORM kullanırken eşlenmiş bir sınıftaki bir yönteme ne tür şeyler gidebilir veya gitmelidir ve başka bir soyutlama katmanında yaşamak için nelerin dışarıda bırakılması gerekir?

Temel kural: sınıf, her koşulda doğru olan veriler hakkında temel gerçekleri tanımlayan bir mantık içermelidir. Bir kullanım durumuna özgü mantık başka bir yerde olmalıdır. Bir örnek doğrulamadır, Martin Fowler'tan içeriğe bağımlı olarak düşünülmesi gereken noktayı ilginç bir makalesi vardır .

Bu, gerçekten geliştirdiğiniz şeyin büyüklüğüne ve ölçeğine bağlı olan bir yargılama çağrısıdır. En katı yaklaşım, ORM tiplerini bir veri erişim bileşeniyle sınırlamak ve ortak bir kütüphanede POCO'ları, tüm katmanlar tarafından başvurulan ve kullanılan tipler olarak kullanmaktır. Bu, gelecekteki fiziksel ayrılmaya ve mantıksal ayrılmaya izin verecektir. Kullanıcı arabirimi ile iş mantığı katmanı arasında ek bir katman olması gerektiğine de karar verebilirsiniz. Buna genellikle Cephe veya İş Arayüzü katmanı denir. Bu ek katman, "kullanım örneği kodunuzun" yaşadığı yerdir. Bireysel gevşek bağlı kod, Facade / BI katmanı tarafından çağrılır (örneğin, Facade, siparişi gerçekten işlemek için gerekli tüm adımları gerçekleştirmek için iş mantığına 1: M kez çağrı yapan bir ProcessOrder () işlevine sahiptir).

Bununla birlikte, tüm bunlar söyleniyor: çoğu zaman bu miktarda mimarlık gereksiz yere aşırıya kaçmak. Örneğin, bileşenlerini yeniden kullanım için paketlemek gibi bir amacınız olmayan basit bir Web sitesine özel olarak kodlayın. Bu tür bir çözüm için bir MVC Web sitesi oluşturmak ve EF nesnelerini kullanmak mükemmel bir şekilde geçerlidir. Sitenin daha sonra ölçeklendirilmesi gerekiyorsa, kümelenmeye veya "yeniden düzenleme" adı verilen sık sık kaybedilen bir sürece bakabilirsiniz.

Sadece bir Java projesiymiş gibi modelleri aşırı yapılandırmanız gerekmediğini meslektaşınıza hatırlatın. Yani, iki kalıcı nesneyi karşılaştırmak davranıştır, ancak kalıcılık katmanı tarafından belirtilmez. Yani 6 bira sorusu şudur: neden aynı şey hakkında bir şeyler tanımlayan tamamen ilgisiz sınıflar var? Elbette, sebat, bir modelin ayrı ayrı ele alınacak kadar büyük bir yönüdür, ancak diğer her şeyden ayrı olarak ele alınacağını garanti etmek için yeterli değildir. Arabanızı sürüyorsanız, yıkayın veya yıkıyorsanız, arabanızı her zaman manipüle edersiniz.

Öyleyse neden tüm bu farklı yönleri tek bir model sınıfında oluşturmuyorsunuz? Kalıcı nesnelerle ilgilenen bir grup sınıf yöntemine ihtiyacınız var - bunları bir sınıfa koyun; doğrulama ile ilgili bir sürü örnek yönteminiz var - bunları başka bir tanesine koyun. Son olarak, ikisini karıştırın ve voila! Kendinize akıllı, kendini tanıyan ve tamamen içerdiği bir model sunumu kazandınız.

Diğer cevaplara ek olarak, bir ORM ile zengin alan modelleri kullanırken gizli mağaralara dikkat edin.

Aşağıdaki sahte kod gibi bir şey elde etmeye çalışırken kalıcı model sınıflarında polimorfik hizmetler enjekte sorunları vardı:

Person john = new Person('John Doe')
Organisation company = organisation_repository.find('some id')
Employee our_collegue_john = company.hire(john)

Bu durumda, bir Kuruluş HRServicebir yapıcı bağımlılığı olarak (örneğin) gerekli olabilir. Bir ORM kullanırken genellikle model sınıflarınızın örneğini kolayca kontrol edemezsiniz.

Doktrin ORM ve Symfony servis kapsayıcısı kullanıyordum. ORM'yi o kadar şık olmayan bir şekilde maymunluk yapmak zorunda kaldım ve kalıcılık ve iş modellerini ayırmaktan başka seçeneğim yoktu. Ben henüz sqlachemy ile denemedim, diye düşündüm. Python, bu şeyler için PHP'den daha esnek olabilir.