Havuz modeli - Neden tam olarak Arayüzlere ihtiyacımız var?

Question

Ben internetten okudum ben Arayüzler Persistance motorunu

değiştirin

bu

• Kullanım TDD yöntemleri için kullanılır diyor bu noktaları var Ama nasıl yeni arayüzde, anlamak mümkün değilim Replace persistance engine numaralı noktaya faydalı olun. Ben Peki arabirimleri resmin içine gelip

  public class EmployeeRepository 
  { 
      public employee[] GetAll() 
      { 
      //here I'll return from dbContext or ObjectContex class 
      } 
  } 
  

  EmployeeRepository için (jenerik hariç) temel depo kuruyorum düşünün sağlar?

  ve varsayalım neden bir upcasting kullanılan bir arabirim oluşturuldu?

  IEmployee emp = new EmployeeRepository() ; 
  vs 
  EmployeeRepository emp = new EmployeeRepository(); 
  

  Lütfen bana Repository Pattern ile ilgili olarak Arayüzün tam olarak ve diğer kullanışlılığını da açıklayınız.

Answer 1

Peki, arayüzler nasıl görünebilir?

Bunun gibi

:

public interface IEmployeeRepository 
{ 
    Employee[] GetAll(); 
} 

ve istediğiniz gibi o zaman birçok uygulamalar olabilir:

public class EmployeeRepositoryEF: IEmployeeRepository 
{ 
    public Employee[] GetAll() 
    { 
     //here you will return employees after querying your EF DbContext 
    } 
} 

public class EmployeeRepositoryXML: IEmployeeRepository 
{ 
    public Employee[] GetAll() 
    { 
     //here you will return employees after querying an XML file 
    } 
} 

public class EmployeeRepositoryWCF: IEmployeeRepository 
{ 
    public Employee[] GetAll() 
    { 
     //here you will return employees after querying some remote WCF service 
    } 
} 

and so on ... you could have as many implementation as you like 

Eğer biz depo nasıl uyguladıklarını gerçekten önemli değil görebileceğiniz gibi.Önemli olan, tüm depoların ve uygulamaların tanımlanan sözleşmeye (arabirim) uygun olması ve çalışanların listesini döndüren tüm GetAll yöntemine sahip olmasıdır.

Ve sonra bu arabirimi kullanan bir denetleyiciniz olacaktır.

public class EmployeesController: Controller 
{ 
    private readonly IEmployeeRepository _repository; 
    public EmployeesController(IEmployeeRepository repository) 
    { 
     _repository = repository; 
    } 

    public ActionResult Index() 
    { 
     var employees = _repository.GetAll(); 
     return View(employees); 
    } 
} 

Denetleyicinin deponun belirli bir uygulamasına nasıl bağlı olmadığına bakın. Tüm bilmesi gereken, bu uygulamanın sözleşmeye saygı duymasıdır. Şimdi yapmanız gereken tek şey, favori bağımlılık enjeksiyon çerçevenizi istediğiniz uygulamayı kullanmak üzere yapılandırmaktır.

1. Ninject.MVC3 Nuget sadece tek bir kod satırı ile EF uygulamasını kullanmaya karar oluşturulan ~/App_Start/NinjectWebCommon.cs kodunda

2. yükleyin:: İşte

   bu Ninject ile yapılır nasıl bir örnek

   private static void RegisterServices(IKernel kernel) 
   { 
       kernel.Bind<IEmployeeRepository>().To<EmployeeRepositoryEF>(); 
   }   
   

artık herhangi manuel instantiations yapmak gerekir Bu şekilde Bu depo sınıfları ve sağanak ya da her neyse endişesi. Bunları sizin için yöneten ve tanımlanmış uygulamayı denetleyici yapıcıya enjekte etmeyi sağlayan bağımlılık enjeksiyon çerçevesidir.

Ve sadece size denetleyicisi tek bir kod satırı dokunmadan veri erişim teknolojisini geçiş olabilir bu yapılandırmayı değiştirerek

. Bu şekilde izolasyonda ünite testi de devreye giriyor. Denetleyici kodunuz artık depoya zayıf bir şekilde bağlandığından (tanıttığımız arabirim sayesinde) birim testinde yapmanız gereken tek şey, depoda davranışını tanımlamanıza izin veren bazı sahte uygulamaların sağlanmasıdır. Bu size, Index denetleyicisinin bir veritabanına veya herhangi bir bağımlılığa bağlı olmadan birim eylemini sınamanızı sağlar. Komple izolasyon.

Ben de following articles ASP.NET MVC TDD ve DI hakkında ödeme davet ediyoruz. hızlı cevap için

Answer 2

Sen bir arayüz olarak deponuzu maruz olacaktır:

public class EmployeeRepository : IEmployeeRepository 
{ 
    public List<Employee> GetAll() 
    { 
     // Return from db. 
    } 
} 

Veya:

public interface IEmployeeRepository 
{ 
    List<Employee> GetAll(); 
} 

Bu tür varsayılan bir şekilde birçok farklı uygulamaları arayüzü, olmasını sağlayacak test bir:

public class TestEmployeeRepository : IEmployeeRepository 
{ 
    public List<Employee> GetAll() 
    { 
     // Stub some dummy data. 
    } 
} 

Sizin kodunuz depo tüketen sonra arayüzünü kullanarak ilgilenir çünkü:

IEmployeeRepository myRepo = MyRepositoryFactory.Get<IEmployeeRepository>(); 

gizli sos fabrika veya kullanılabilir bir türü içine arayüzü çözmek için başka mekanizmadır (örneğin Ninject veya Kalesi gibi Bağımlılık Enjeksiyon çerçevesi Windsor bu görevi yerine getirecek).

noktasıdır, tüketen kod uygulaması, sadece sözleşme (arayüz) umursamıyor. Bu, test amaçlı uygulamalarınızı çok kolay bir şekilde değiştirmenize ve gevşek kuplajı teşvik etmenize olanak tanır.

Sadece açıklığa kavuşturmak gerekirse, arayüzlerin kullanımı ile havuz kalıbı arasında özel bir bağlantı yoktur, sadece bunları kullanabilen başka bir modeldir.