2016-04-19 2 views
2

Ich arbeite daran, Projekte zu strukturieren und stoße auf Zwiebelarchitektur. Soweit ich es verstehe, handelt es sich eher um eine domänenzentrierte Fokusarchitektur als um einen datenbankgestützten Typ.Wieso in der Onion Architecture den Service anstelle des Repositorys verfügbar machen?

Ich suche nach einigen GitHub Projekte mehr über die Architektur zu studieren und zu lernen, so fand ich dieses https://github.com/chetanvihite/OnionArchitecture.Sample

Ich habe eine harte Zeit Verständnis mit:

namespace Domain.Interfaces 
{ 
    public interface IUserRepository 
    { 
     IEnumerable<User> GetUsers(); 
    } 
} 

namespace Services.Interfaces 
{ 
    public interface IUserService 
    { 
     IEnumerable<User> GetUsers(); 
    } 
} 

namespace Services 
{ 
    public class UserService : IUserService 
    { 
     private readonly IUserRepository _repository; 

     public UserService(IUserRepository repository) 
     { 
      _repository = repository; 
     } 

     public IEnumerable<User> GetUsers() 
     { 
      return _repository.GetUsers(); 
     } 
    } 
} 

Wie er benutzt es ist durch Konstruktorinjektion.

private readonly IUserService _service; 

public HomeController(IUserService service) 
{ 
    _service = service; 
} 
  1. Setzen Sie immer einen Dienst wie IUserService zu einer App, die es verbraucht? Aber ich habe bemerkt, IUserRepository hat die gleichen Methoden wie IUserService?

  2. Wenn Sie sagen Infrastructure betrifft, bedeutet es, oder beinhaltet es eine Datenbank? Oder nicht unbedingt? Wenn nicht, was sind Beispiele für Infrastrukturprobleme?

  3. Haben Sie eine Empfehlung zu kostenlosen Projekten/github-Projekten, die ich herunterladen kann, um mehr über Zwiebelarchitektur zu erfahren oder zu lernen? Ich verstehe besser auf Beispiele

P. S. Als ich Zwiebel Architektur lerne, es immer, wenn nicht immer, zumindest erwähnt es über DDD. Also ich denke, ich werde DDD auch lernen :)

+2

Ein sehr guter Artikel über die verschiedenen Arten von Dienstleistungen in DDD, mit einigem Code: http://gorodinski.com/blog/2012/04/14/services-in -domain-driven-design-ddd/ – guillaume31

Antwort

6

1. Repository vs. Service:

Möglicherweise möchten Sie eine Antwort auf die difference between repositories and services und/oder Martin Fowlers service layer Definition lesen. Kurz gesagt, ein Repository behandelt die Datenpersistenz, während ein Service eine Client-orientierte API für die Geschäftslogik bereitstellt.

In dem gegebenen kleinen Beispiel die Vorteile möglicherweise nicht klar sein, aber stellen Sie sich vor die UserService hatte zusätzliche Methoden wie lockUser(User user) oder joinGroup(User user, Group group). Die UserService verwendet dann jedeIUserRepository Implementierung, um tatsächlich die Geschäftslogik zu bestehen.

2. Infrastruktur Bedenken

Die Infrastrukturschicht typischerweise auf externen Ressourcen spricht, wie Dateisysteme, Datenbanken oder Web-Services. In Ihrem Beispiel ist die IUserRepository Teil der Infrastrukturschicht.

3. Beispiele

Eine Sammlung von Beispielen I (mit * gekennzeichnet) kennen und einige, die ich gerade gefunden:

+0

Vielen Dank für die Referenzen. Wirklich zu schätzen, aber in 1. Das heißt nicht, dass ich die gleichen Methoden wie lockUser und joinGroup im Repository erstellen muss, oder? –

+0

Ja, angenommen, das 'IUserRepository' bietet einfache CRUD-Methoden für das Benutzerobjekt. Die 'UserService.lockUser (userToLock)' - Methode ändert dann den Status des Benutzerobjekts (z. B. durch 'userToLock.lock()') und hält es dann unter Verwendung des Repositorys (z. B. durch _repository.save (userToLock)). Die Kapselung erleichtert das Hinzufügen von übergreifenden Problemen unabhängig von der tatsächlichen Persistenzimplementierung für den UserService, z. B. Zugriffssteuerung, Ereignisauslösung, Protokollierung, ... –

Verwandte Themen