Depo kalıbı nasıl doğru kullanılır?

Depolarımı nasıl gruplandırmalıyım merak ediyorum? Asp.net mvc'de gördüğüm örneklerde olduğu gibi ve kitaplarımda temelde veritabanı tablosu başına bir depo kullanıyorlar. Ancak bu, daha sonra alay etmek ve benzeri şeyler için birçok depoyu aramak zorunda kalmanıza yol açan birçok depo gibi görünüyor.

Bu yüzden onları gruplandırmam gerektiğini tahmin ediyorum. Ancak onları nasıl gruplandıracağımdan emin değilim.

Şu anda tüm kayıt işlerimi idare etmek için bir kayıt Havuzu oluşturdum. Ancak güncellemem gereken 4 tablo var ve bunu yapmak için 3 depomuz vardı.

Örneğin tablolardan biri bir lisans tablosudur. Kayıt olduklarında anahtarlarına bakar ve veritabanında olup olmadığını kontrol ederim. Şimdi bu lisans anahtarını veya bu tablodan kayıttan başka bir yerde başka bir şeyi kontrol etmem gerekirse ne olur?

Bir nokta giriş olabilir (anahtarın süresinin dolup dolmadığını kontrol edin).

Peki bu durumda ne yapacağım? Kodu yeniden yazmak (DRY'yi kırmak)? Bu 2 depoyu bir araya getirmeye çalışın ve yöntemlerden hiçbirinin başka bir zamanda gerekli olmayacağını umun (örneğin, userName kullanılıp kullanılmadığını kontrol eden bir yöntemim olabilir - belki buna başka bir yerde ihtiyacım olabilir).

Ayrıca, eğer onları bir araya getirirsem, aynı depoya giden 2 hizmet katmanına ihtiyacım olur, çünkü bir sitenin 2 farklı bölümü için tüm mantığa sahip olmanın uzun olacağını ve ValidateLogin (), ValdiateRegistrationForm () gibi isimlere sahip olmam gerektiğini düşünüyorum. , ValdiateLoginRetrievePassword () vb.

Ya da Depoyu yine de arayın ve etrafta kulağa tuhaf gelen bir isim mi var?

Yeterince genel bir ada sahip bir havuz yapmak zor görünüyor, böylece uygulamanızın birçok noktası için kullanabilirsiniz ve yine de mantıklı ve bir depodaki başka bir depoyu çağırmanın iyi bir uygulama olacağını düşünmüyorum?

Depo modeliyle oynadığımda yanlış yaptığım bir şey - tıpkı sizin gibi, tablonun depo 1: 1 ile ilgili olduğunu düşündüm. Etki Alanı Odaklı Tasarımdan bazı kuralları uyguladığımızda - havuzları gruplama sorunu genellikle ortadan kalkar.

Depo, tablo değil, Toplama kökü başına olmalıdır . Bu, - eğer varlık yalnız yaşamamalıysa (yani - Registrantözellikle katılan Registrationbir varlığa sahipseniz ) - sadece bir varlıktır, bir depoya ihtiyaç duymaz, toplu kök deposu aracılığıyla güncellenmeli / oluşturulmalı / alınmalıdır. aittir.

Elbette - çoğu durumda, bu depo sayısını azaltma tekniği (aslında - daha çok alan modelinizi yapılandırmak için bir tekniktir) uygulanamaz çünkü her varlığın bir toplu kök olması gerekir (bu büyük ölçüde alan adınıza bağlıdır, Yalnızca kör tahminler sağlayabilirim). Örneğinizde - Licensetoplu bir kök gibi görünüyor çünkü onları Registrationvarlık bağlamı olmadan kontrol edebilmeniz gerekiyor .

Ancak bu bizi depoları basamaklamakla sınırlamaz ( Registrationhavuz, Licensegerekirse depoya başvurabilir). Bu bizi Licensedoğrudan Registrationnesneden veri havuzuna (tercihen - IoC aracılığıyla) başvurmakla kısıtlamaz .

Tasarımınızı teknolojilerin sağladığı karmaşıklıklardan veya bir şeyi yanlış anlamadan yönlendirmemeye çalışın. Depoları ServiceXsırf 2 depo inşa etmek istemediğiniz için gruplamak iyi bir fikir değildir.

Buna uygun bir ad vermek çok daha iyi olur - RegistrationServiceyani

Ancak genel olarak hizmetlerden kaçınılmalıdır - bunlar genellikle anemik alan modeline yol açan nedenlerdir .

DÜZENLEME:
IoC'yi kullanmaya başlayın. Bağımlılık enjekte etmenin acısını gerçekten hafifletir.
Yazmak yerine:

var registrationService = new RegistrationService(new RegistrationRepository(),  
      new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds());

yazabileceksiniz:

var registrationService = IoC.Resolve<IRegistrationService>();

Ps Sözde ortak servis bulucuyu kullanmak daha iyi olurdu ama bu sadece bir örnek.

Bunu ele almak için yapmaya başladığım bir şey, aslında N depoları saran hizmetler geliştirmektir. Umarım DI veya IoC çerçeveleriniz bunu kolaylaştırmaya yardımcı olabilir.

public class ServiceImpl {
    public ServiceImpl(IRepo1 repo1, IRepo2 repo2...) { }
}

bu mantıklı mı? Ayrıca, bu malikanedeki hizmetlerden bahsetmenin DDD ilkelerine uyup uymayabileceğini anlıyorum, sadece işe yarıyor gibi göründüğü için yapıyorum.

Yaptığım şey şu şekilde tanımlanan soyut bir temel sınıfım var:

public abstract class ReadOnlyRepository<T,V>
{
     V Find(T lookupKey);
}

public abstract class InsertRepository<T>
{
     void Add(T entityToSave);
}

public abstract class UpdateRepository<T,V>
{
     V Update(T entityToUpdate);
}

public abstract class DeleteRepository<T>
{
     void Delete(T entityToDelete);
}

Daha sonra, soyut temel sınıftan deponuzu türetebilir ve örneğin genel argümanlar farklı olduğu sürece tek deponuzu genişletebilirsiniz;

public class RegistrationRepository: ReadOnlyRepository<int, IRegistrationItem>,
                                     ReadOnlyRepository<string, IRegistrationItem> 

vb....

Ayrı depolara ihtiyacım var çünkü bazı depolarımızda kısıtlamalarımız var ve bu bize maksimum esneklik sağlıyor. Bu yardımcı olur umarım.

Bunu depo sınıfım olarak aldım ve evet tablo / alan deposunda genişletiyorum ama yine de bazen DRY'yi kırmam gerekiyor.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MvcRepository
{
    public class Repository<T> : IRepository<T> where T : class
    {
        protected System.Data.Linq.DataContext _dataContextFactory;

        public IQueryable<T> All()
        {
            return GetTable.AsQueryable();
        }

        public IQueryable<T> FindAll(Func<T, bool> exp)
        {
            return GetTable.Where<T>(exp).AsQueryable();
        }

        public T Single(Func<T, bool> exp)
        {
            return GetTable.Single(exp);
        }

        public virtual void MarkForDeletion(T entity)
        {
            _dataContextFactory.GetTable<T>().DeleteOnSubmit(entity);
        }

        public virtual T CreateInstance()
        {
            T entity = Activator.CreateInstance<T>();
            GetTable.InsertOnSubmit(entity);
            return entity;
        }

        public void SaveAll()
        {
            _dataContextFactory.SubmitChanges();
        }

        public Repository(System.Data.Linq.DataContext dataContextFactory)
        {
            _dataContextFactory = dataContextFactory;
        }

        public System.Data.Linq.Table<T> GetTable
        {
            get { return _dataContextFactory.GetTable<T>(); }
        }

    }
}

DÜZENLE

public class AdminRepository<T> : Repository<T> where T: class
{
    static AdminDataContext dc = new AdminDataContext(System.Configuration.ConfigurationManager.ConnectionStrings["MY_ConnectionString"].ConnectionString);

    public AdminRepository()
        : base( dc )
    {
    }

Ayrıca Linq2SQL.dbml sınıfı kullanılarak oluşturulmuş bir veri bağlamım var.

Artık Hepsi ve Bul gibi standart çağrıları uygulayan standart bir depom var ve Yönetici Depomda belirli çağrılarım var.

KURU sorusunun cevabını sanmıyorum da.

FluentNHibernate kullanan genel bir Depo uygulamasının bir örneğini burada bulabilirsiniz . Eşleştirici yazdığınız herhangi bir sınıfı sürdürebilir. Hatta eşleyici sınıflarından yola çıkarak veritabanınızı oluşturabilir.

Depo kalıbı kötü bir tasarım kalıbıdır. Birçok eski .Net projesiyle çalışıyorum ve bu model genellikle önlenebilecek "Dağıtılmış İşlemler", "Kısmi Geri Alma" ve "Bağlantı Havuzu Tükendi" hatalarına neden oluyor. Sorun, modelin bağlantıları ve işlemleri dahili olarak ele almaya çalışması, ancak bunların Denetleyici katmanında ele alınması gerektiğidir. Ayrıca EntityFramework zaten mantığın çoğunu özetliyor. Paylaşılan kodu yeniden kullanmak yerine Hizmet modelini kullanmanızı öneririm.

Sharp Mimarlık'a bakmanızı öneririm . Varlık başına bir depo kullanılmasını önerirler. Şu anda projemde kullanıyorum ve sonuçlardan memnun kaldım.