Veritabanı tablosu başına modeller?

Codeigniter kullanıyorum ve kendimi benzer bir durumda buldum nerede Model yöntemleri tekrarladı. Denetleyici başına bir Model oluşturuyorum. Ama veritabanı tablo başına bir Model oluşturmak iyi uygulama olarak kabul edilir? Bu şekilde yöntemler iki kez yazılmaz.

Denetleyici başına Model veya Paylaşılan birkaç küçük Model yerine.

Örnek bir get_user ($ user_id) model yöntemim varsa bunu users_models.php üzerine yazabilirim ...

Bunu gördüğüm dezavantajlardan biri, sadece controllername_models.php yerine birkaç modeli çağırmam gerekebileceğidir.

Bir denetleyiciden çeşitli yöntemlerin kullanılmayabileceği birkaç modelin yüklenmesi performansı ve hızı etkileyebilir mi? Bunu çözmenin en iyi yolu ne olabilir?

Not: Benzer bir soru vardır, ancak veritabanı tablosu başına Model zeminini kapsamazlar.

Tablo başına bir modelin sadece veritabanınızı bir sınıf yapısında yeniden oluşturduğunu söylüyoruz. Anemik bir model olarak bilinir ve bir anti-desen olarak kabul edilir. Bunun nedeni, sınıfların hem veriye hem de davranışa sahip olmalarıdır. Modellerinizi tek bir tabloyla kısıtlarsanız, birden çok tablodan veri ve davranışla ilgilenmesi gereken kodu (davranış) nereye koyarsınız? Daha sonra denetleyicileriniz bu "tablo" modellerinden birini veya daha fazlasını kullanan modellere ihtiyaç duyacaktır ... Yani, en temel uygulamaların dışında, bu yaklaşımdan bir şey elde ederseniz çok az kazanırsınız.

Genel olarak modellerinizi tablo veya denetleyici başına değil, işletme nesnesi başına oluşturmalısınız. Bazen tablo yapınızla veya denetleyicilerinizle 1: 1 ilişki olabilir, ancak gerekli değildir.

users_modelÖrneğinizde, birkaç denetleyiciden çağrılan bir sınıfınız olabilir . Bu iyi ve hatta bazen arzu edilir. Ancak çoğu durumda users_modelsınıf verilerini birkaç tablodan alır.
Örneğin last_login_date, users_modelsınıfın özelliği , ana tabloyla bir -çok ilişkisi olan ayrı bir tablodan edinilebilir ( zorunlu değildir ) .user_auditusers

Ve iş nesnesi başına bir SQL tablonuz varsa, o zaman büyük olasılıkla veritabanı yapınızın normalleştirilmiş olmadığını söyleyebilirim.

Çoğunlukla Dime'ın iş nesnesi başına modellerinizi oluşturmak istediğiniz cevabına katılıyorum - işletmenin çözmeye çalıştığı sorunlar, model sınıflarını nasıl yarattığınızı yönlendirmelidir. Uygulamada, tablo başına bir model oluşturmanın başlamak için iyi bir yer olduğunu gördüm. Düzgün tasarlanmış bir şemanın, Etki Alanı Modeli olarak da adlandırılan uygulama kodunda modellemeniz gereken iş süreçlerini taklit etmesi muhtemeldir.

Bir Nesne / İlişkisel Eşleme katmanı kullanmak, Alan Modeli'nizin bir veri erişim katmanına tekrarlayan çağrılara gerek kalmadan veritabanı şemasıyla aynı ilişkileri içermesi açısından kullanışlıdır. Örnek olarak PHP için Eloquent'a göz atın . Hem şema hem de Alan Modeli, iş süreçlerini destekleyecek şekilde tasarlanmalıdır.

Bu Marjan Venema'nın cevabının ilk kısmına yol açar:

Tablo başına bir modelin sadece veritabanınızı bir sınıf yapısında yeniden oluşturduğunu söylüyoruz. Anemik bir model olarak bilinir ve bir anti-desen olarak kabul edilir.

Bir anemik Alan Modeli , anti-desenidir. Venema'nın önerdiği gibi "tablo başına model", "veritabanınızı yeniden oluşturma" olarak görülebilir, ancak bunun tek başına bir Anemik Alan Modeli olduğunu söylemek kesinlikle yanlıştır.

Martin Fowler'tan:

Anemik Alan Modelinin temel belirtisi, ilk bakışta gerçek olana benziyor olmasıdır. Birçoğu etki alanı alanındaki adlardan sonra adlandırılan nesneler vardır ve bu nesneler gerçek etki alanı modellerinin sahip olduğu zengin ilişkiler ve yapı ile bağlantılıdır. Yakalama, davranışa baktığınızda gelir ve bu nesneler üzerinde neredeyse hiç davranış olmadığını fark edersiniz, bu da onları alıcıların ve ayarlayıcılardan biraz daha fazla hale getirir.

(vurgu, benim)

Anemik etki alanı modelindeki anahtar faktör, Etki Alanı Modeli sınıflarında davranış veya yöntem eksikliğidir.

Çünkü sınıflar hem verilere hem de davranışa sahip olmaları amaçlanmıştır. Modellerinizi tek bir tabloyla kısıtlarsanız, birden çok tablodan veri ve davranışla ilgilenmesi gereken kodu (davranış) nereye koyarsınız?

Yine, yalnızca bir tabloyla eşleşseler bile Etki Alanı Modellerinize davranış koyabilir ve eklemelisiniz. Birden çok tabloyu etkileyen davranış, birden çok tabloyla eşleştirilen birden çok nesneyi gerçekten etkiler. Etki Alanına Dayalı Tasarım tam olarak aynı soruna bir yaklaşım Venema bahsetti: "birden çok tablodan veri ve davranış ile başa çıkmak için gereken kodu (davranış) nereye koyarsınız?"

Ve cevap bir Toplam Köktür . Martin Fowler şunları söylüyor:

Agrega, Etki Alanına Dayalı Tasarımda bir modeldir. DDD toplamı, tek bir birim olarak ele alınabilen bir etki alanı nesneleri kümesidir. Bir örnek bir sipariş ve satır öğeleri olabilir, bunlar ayrı nesneler olacaktır, ancak siparişi (satır öğeleriyle birlikte) tek bir toplu olarak ele almak yararlıdır.

(vurgu, benim)

"Etki alanı nesneleri kümesi", "Birden çok tabloyla eşleşen Etki Alanı Modelleri" olarak da görüntülenebilir. Birden çok tabloyu etkileyen davranış, Toplam Kökte tanımlanmalıdır - Birden çok tablo veya nesneyi etkileyen "şey" i içine alan bir sınıf:

Yine Martin Fowler'tan:

Bir agrega genellikle basit alanlarla birlikte çoklu koleksiyonlar içerir.

OP'nin orijinal sorusunu cevaplamak için:

... veritabanı tablosu başına bir Model oluşturmak iyi bir uygulama olarak kabul edilir mi? Bu şekilde yöntemler iki kez yazılmaz.

Bunun başlamak için iyi bir yer olduğunu söyleyebilirim, ancak şemanızın ve nesne modelinizin% 100 eşleşmesi gerekmediğini unutmayın. Nesne modeli, iş kurallarının uygulanması ve yürürlüğe konması ile daha fazla ilgilenmelidir. Şema, iş verilerini modüler ve ölçeklenebilir bir şekilde saklamaya daha fazla odaklanmalıdır.

Bir Görünüm Modeli denilen modelin bir varyasyonu olmasına rağmen denetleyici başına bir model, iyi bir uygulama olmaz yapar Kontrolör katmanına uyum. Bir Görünüm Modeli , ekranın belirli bir tür sığdırmak o bir GUI uygulamasında bir web sayfası veya form olarak Alan Modelinin bir reorganizasyon olduğunu.