Bir MVC sisteminde, veritabanı kalıcılık kodu nereye oturmalıdır?

21

Veritabanına bilgi vermek için birden çok yapılandırma gördüm. Genel olarak, dünya köşemde üç tip tasarım yaygın görünüyor:

Denetleyici kalıcılığı yönetir
Model kalıcılığı yönetir
Üçüncü taraf kütüphanesi, model üzerinde bir tür ek açıklama gerektiren, kalıcılığı yönetir.

Bir MVC mimarisiyle hangi yapılandırmanın (varsa) kavramsal olarak kullanımı en kolay / en uyumlu olduğunu merak ediyorum?

(Eğer listelediğim bir değilse, lütfen cevabın bir parçası olarak hızlı bir taslak / genel bakış verin)

mvc

— blueberryfields
kaynak

13

İkinci ve üçüncü seçenekleriniz aynı. MVC'deki M, veri modeli değil, etki alanı modelidir. Bu, ister doğrudan ister bir ORM aracılığıyla yapılmış olsun, ve her ikisini de mükemmel bir şekilde sürdürmeyi içerir.

Denetleyici, sitenin akışını yönetmeli ve işlenecek şeyleri etki alanına (bazen bir servis katmanı aracılığıyla) aktarmalıdır, bu nedenle oradan devam etmek yanlış - veya en azından semantik olarak rahatsız edicidir.

— pdr
kaynak

2

Bir dereceye kadar katılmıyorum. Kalıcılığın somut kullanımı uygulama mantığıdır ve bu nedenle etki alanı Katmanına değil uygulama Katmanına aittir. Etki alanı katmanı (etki alanı modelini içeren) gündelik iş programı için ısrarcı olmamalıdır. Kontrolör bir orkestratördür . (Veri-) hizmetleri, kullanıcı arayüzü ve etki alanı modelini düzenleyebilir.

— Falcon

1

@Falcon: Kontrolör verilerin ne zaman yüklenip veritabanına yüklendiğini kontrol etmeli olsa da , bunu modele söylemesi tamamen doğru. Bir ORM kullanmak (standart veya kendinize ait bir rulo) genellikle modele yükleme / kaydetme demeyi ve ardından ORM'ye yetki vermeyi ifade eder. Başka bir yol, kontrol cihazının bir ORM'ye, yüklemek için bir model sınıfından geçen bir şeyi (seçim kriterleri ile) ya da kaydetmek için örnek bir örneği yüklemesini / kaydetmesini bildirmesi olabilir. Her iki durumda da, gerçek yükleme / tasarruf modele yakından bağlı olacaktır.

— Marjan Venema

@Marjan Venema: Evet, katılıyorum, ancak soru bu kodun nerede olması gerektiği. Modeli mümkün olduğunca ısrarcı görmezden gelmeye çalışıyorum ve etki alanı öğelerini yalnızca davranışları ve etkileşimleriyle modelleyeceğim. Başka herhangi bir şey uygulama katmanlarında yaşayacak (modelimin bir uygulaması olduğu gibi). Haritalama bilgileri / veri erişimi, etki alanı modelinden tamamen ayrıştırılır ve ayrıca sürümlendirme (yükseltme / düşürme) ile de ilgilenebilir. Veri erişiminin uygulanması aynı zamanda uygulama katmanlarında da (hizmet, depo vb. İçeren) yaşar

— Falcon

@Falcon: Evet, bunu yapmanın iyi bir yolu ve geçmişte ayrı haritalandırma sınıfları kullanarak nasıl yaptığımdır. Bununla birlikte, genişletilmiş RTTI (Delphi) ve yansıma (.Net ve diğerleri) ile birlikte, bunları İş Nesnesi Modeli'nin özelliklerinin açıklanmasıyla bağlantılı olarak kullanmama ve hiçbir şeyi aşmayacak ve sadece kod kancaları ve / veya veri tabanı sürümüne dikkat etmek için özel olarak kodlanmış başlatma sınıfları.

— Marjan Venema,

5

Gerçekçi olarak, MVC çoğunlukla bir UI uygulama modelidir, bu yüzden soru biraz tartışmalıdır. Ancak, gerçekten sadece iki büyük resim seçeneği var. Kontrol cihazınız tipik olarak 1) bir tür servis katmanı veya 2) Aktif Kayıt kalıbı kullanarak modelinizde varlıkları yükleme veya kaydetme isteklerini gönderir.

Hizmet katmanı, herhangi bir şekilde olabilir, ancak benim kişisel tercihim, somut uygulamaları bir tür ORM veya hafif bir DAO ile çalışacak olan toplu kök varlıklar için depo soyutlamasıyla çalışmaktır. Uygulama için anlamlı olan bazı ilişkisel olmayan mağazalar için API.

Aktif Kayıt kalıbı, modelinizin kalıcılıktan sorumlu olduğu anlamına gelir, ancak genellikle bir çeşit temel sınıf anlamına gelir, mağazanızdaki eşlemeleri yönetir, bu nedenle modeliniz tam olarak o kadar doğrudan ilişkili değildir.

Temel olarak, denetleyici, depolarınıza, UnitOfWork uygulamanıza veya varlıklarınızdaki Kaydet yöntemine yapılan bir çağrı olup olmadığına, nesnelere yönelik istekleri gönderir. Havuz kullanıyorsanız, model nesneleriniz ısrarcı-cahildir.

— JasonTrue
kaynak

3

Bir MVC (model-görünüm-kontrol cihazı) sisteminde, model verileri içerir. Bu yüzden veritabanının kalıcılığının içinde olması gerektiğine inanıyorum.

— Nettogrof
kaynak

2

Gördüğüm en üst düzey MVC örnekleri infrastructure, gerçek veritabanı uygulama koduna sahip (yani NHibernate veya EF veya Linq'e özel çağrılar veya veri katmanınız ne olursa olsun), "model" katmanı (genellikle ayrıca "Domain" katmanı) veri servislerini tanımlayan arayüzlere sahiptir.

— Wayne Molina
kaynak

0

MVC'deki standart uygulama, M (odel) katmanında veri yapısını ve kalıcılığını içermektir.

Model katmanı yalnızca uygulamanızda kullanacağınız sınıfları (POCO'lar vb.) İçermez. Bu sınıflar için depoları içerirler.

Bir örnek, birçok veri sınıfı örneği bulunduğunuz bir depo olabilir, örneğin:

Clients repository

AllClients()
RecentClients()
ClientByID(int id)

Model etki alanınızı daha iyi düzenleyebilecek ve verilerinize birçok yolla erişebileceksiniz, ancak yine de veri / model katmanı küçük ve sağlam olacak

— Mihalis Bagos
kaynak