ORM katmanı üzerinde bir soyutlama katmanı oluşturma

Havuzlarınız varsa, veritabanından zaten soyutlanmış bir ORM kullandığınıza inanıyorum.

Ancak, şu anda çalıştığım yerde, birisi daha sonra ORM'yi değiştirmek istediğimizde ORM'yi soyutlayan bir katmana sahip olmamız gerektiğine inanıyor.

Birçok ORM üzerinde çalışacak bir katman oluşturmak gerçekten gerekli mi yoksa başın üstünde mi?

Düzenle

Daha fazla ayrıntı vermek için:

1. AutoMapper ile eşlenen POCO sınıfımız ve Entity Sınıfımız var. Varlık sınıfı, Depo katmanı tarafından kullanılır. Depo katmanı daha sonra Entity Framework ile iletişim kurmak için ek soyutlama katmanını kullanır.
2. İş katmanının hiçbir şekilde Entity Framework'e doğrudan erişimi yoktur. ORM üzerinde ek bir soyutlama katmanı olmasa bile, bunun depo katmanını kullanan hizmet katmanını kullanması gerekir. Her iki durumda da, iş katmanı ORM'den tamamen ayrılmıştır.
3. Ana argüman gelecekte ORM'yi değiştirebilmektir. Depo katmanının içinde gerçekten yerel olduğundan, bana çok iyi ayrılmış durumda ve neden "kalite" koduna sahip olmak için ek bir soyutlama katmanının gerekli olduğunu görmüyorum.

Bu şekilde delilik yatar. ORM'leri değiştirmeniz gerekmeyecektir. ORM'yi değiştirmeye karar verirseniz, eşlemeleri yeniden yazmanın maliyeti, kendi meta-ORM'nizi geliştirme ve sürdürme maliyetinin küçük bir kısmı olacaktır. ORM'leri değiştirmek için gereken işin% 95'ini yapmak için birkaç komut dosyası yazmanızı bekleyebilirim.

Şirket içi çerçeveler neredeyse her zaman bir felakettir. Gelecekteki ihtiyaçların beklentisiyle bir tane inşa etmek neredeyse garantili bir felakettir. Başarılı çerçeveler, hayali ihtiyaçları karşılamak için önceden inşa edilmeyen başarılı projelerden çıkarılır.

ORM, veri katmanınızın RDBMS'sinden bağımsız olması için bir soyutlama sağlar, ancak iş katmanınızı veri katmanınızdan "çözmek" için yeterli olmayabilir. Özellikle, RDBMS tablolarıyla eşlenen nesnelerin doğrudan iş katmanına "sızmasına" izin vermemelisiniz.

En azından işletme katmanınızın, veri katmanındaki ORM tarafından yönetilen, tablo eşlemeli nesnelerinizin potansiyel olarak uygulayabileceği arabirimlere programlaması gerekir. Ayrıca, ORM'nizin yerel sorgulama özelliklerini gizlemek için arabirim tabanlı bir soyut sorgu oluşturma katmanı oluşturmanız gerekebilir. Ana hedef, belirli bir ORM'yi veri katmanının ötesinde çözümünüzde "pişirmekten" kaçınmaktır. Örneğin , iş katmanında HQL ( Hazırda Bekleme Sorgu Dili ) dizeleri oluşturmak cazip gelebilir . Ancak, bu görünüşte masum bir karar, iş katmanınızı Hazırda Bekletme'ye bağlar, böylece iş ve veri erişim katmanlarını bir araya getirir; bu durumdan mümkün olduğunca kaçınmaya çalışmalısınız.

DÜZENLEME: Sizin durumunuzda, havuzun içindeki ek katman zaman kaybıdır: ikinci noktanıza bağlı olarak, iş katmanınız deponuzdan yeterince yalıtılmıştır. Ek yalıtım sağlamak, hiçbir ek fayda olmadan gereksiz karmaşıklık getirecektir.

Deponuzun içinde fazladan bir soyutlama katmanı oluşturmayla ilgili sorun, ORM'in belirli "markasının" onunla etkileşim şeklinizi belirlemesi. ORM'nize benzeyen ancak kontrolünüz altında olan ince bir ambalaj oluşturursanız, alttaki ORM'yi değiştirmek kabaca bu ek katman olmadan olduğu kadar sert olacaktır. Öte yandan, ORM'nize benzemeyen bir katman oluşturursanız, nesne-ilişkisel haritalama teknolojisi seçiminizi sorgulamalısınız.

UnitOfWork genellikle bu soyutlamayı sağlar. Değişmesi gereken bir yer, depolarınız bir Arayüz üzerinden ona bağlı. O / RM'yi değiştirmeniz gerekirse, üzerine yeni bir UOW uygulayın. Bir ve bitti.

BTW sadece O / RM'yi değiştirmenin ötesine geçer, birim testini düşünün. Üç tane UnitOfWork uygulamam var, biri EF, biri NH için (çünkü aslında Oracle desteği isteyen bir istemci için O / RM'leri proje ortasında değiştirmek zorunda kaldım) ve diğeri InMemory kalıcılığı için. InMemory sürekliliği, bir veritabanını arkasına koymaya hazır olmadan önce birim testleri ve hatta hızlı prototipleme için mükemmeldi.

Çerçevenin uygulanması kolaydır. Önce jenerik IRepository arayüzünüz var

public interface IRepository<T>
  where T:class
{
  IQueryable<T> FindBy(Expression<Func<T,Bool>>filter);
  IQueryable<T> GetAll();
  T FindSingle(Expression<Func<T,Bool>> filter);
  void Add(T item);
  void Remove(T item);

}

Ve IUnitOfWork arayüzü

public interface IUnitOfWork
{
   IQueryable<T> GetSet<T>();
   void Save();
   void Add<T>(T item) where T:class;
   void Remove<T>(T item) where T:class;
}

Sonraki temel depo (soyut olup olmayacağına dair seçiminiz

public abstract class RepositoryBase<T>:IRepository<T>
  where T:class
{
   protected readonly IUnitOfWork _uow;

   protected RepositoryBase(IUnitOfWork uow)
   { 
      _uow=uow;
   }

   public IQueryable<T> FindBy(Expression<Func<T,Bool>>filter)
   {
      return _uow.GetSet<T>().Where(filter);
   }

   public IQueryable<T> GetAll()
   {
      return _uow.GetSet<T>();
   }

   public T FindSingle(Expression<Func<T,Bool>> filter)
   {
      return _uow.GetSet<T>().SingleOrDefault(filter);
   }

   public void Add(T item)
   {
      return _uow.Add(item);
   }

   public void Remove(T item)
   {
      return _uow.Remove(item);
   }
}

IUnitOfWork'un uygulanması EF, NH ve In Memory için çocuk oyunudur. IQueryable'ı iade etmemin nedeni, aynı nedenden dolayı, Ayende görevinde belirtildi, müşteri LINQ kullanarak sonucu daha fazla filtreleyebilir, sıralayabilir, gruplayabilir ve hatta yansıtabilir ve yine de sunucu tarafında yapılıyor.