ASP.NET MVC3 - 3-Tier-design - Transaktion Kontroll-und business-Schicht-design Fragen

Ich bin der Gestaltung eines ASP.NET MVC3-Anwendung, und ich möchte eine klare Trennung der Interessen in einem 3-Schicht-Architektur. Ich bin mit Fluent NHibernate als ORM, die Repository-pattern für die Arbeit mit den Entitäten zugeordnet, die von NHibernate. Ich möchte hinzufügen, eine richtige business-Schicht mit einer Unit Of Work pattern, halten die MVC-Teil nur für die Präsentation (durch die Verwendung von ViewModels, die Karte, um die nHibernate Unternehmen über die business-Schicht). Dieser Artikel beschreibt die kombinierte 3-tier und MVC-Architekturen schön.

Gemäß dieser MVC + - Einheit von Arbeit + repository Artikel sehe ich nicht eine klare Unterscheidung von ein business-Schicht. Die Einheit von Arbeit, Klasse präsentiert, stark typisierte Getter für jedes repository-Typ, der schaut, geeignet für eine business-Schicht. Jedoch, es stellt eine Methode zum Speichern, die ich denke, würde übersetzen, um BeginTransaction und CommitTransaction Methoden mit nHibernate. Dies wirft einige Fragen auf:

1) Ist die Offenlegung der Transaktion die Kontrolle zu MVC-eine gute Idee? Auf welcher Stufe sollte die Transaktion Kontrolle passieren? Mir scheint, dass MVC sollten nicht verantwortlich für Transaktionen, aber wie kann man das vermeiden?

2) Sollte es werden einige automatische Weg, um Transaktionen? Das ActionFilter Umsetzung ist semi-automatisch, aber die transaction control ist eindeutig in der MVC-Abschnitt, der nicht der business-Schicht.

3) Ist das UnitOfWork-Klasse das gleiche wie ein business-Schicht-Klasse?

- wenn dem so ist, bedeutet das, wir können fügen Sie benutzerdefinierte business-logic-Methoden in es?

- wenn nicht, wickeln wir die Einheit der Arbeit mit einigen anderen Klasse(N) enthält, die business-logic-Methoden?

Ich Schätze irgendwelche Ideen oder Beispiele. Danke.

InformationsquelleAutor Alex | 2011-10-14
  1. 12

    Zunächst möchte ich zur Klärung ein wenig mis-Konzeption über die business-Schicht, wie Sie möchten, so verwenden Sie das Repository-pattern und Ihre Einrichtung ist auch ein Kandidat Domain-Driven Design, dann die business-Schicht ist eigentlich [Domain Model ( Entitäten und Wertobjekte , wo Sie entwerfen Sie Ihre business-Logik in einer Objekt-orientierten Art und Weise in Unternehmen und Objekte) und die Application-Ebene zu koordinieren, Transaktionen und Operationen und Befehle, um die domain-Schicht], so wird die vorgeschlagene Architektur wäre so etwas wie dieses:

    • Darstellung (MVC) [OrderView, OrderPresentationModel, OrderController]
    • Anwendung [OrderService]
      • Verwenden UnitOfWork (Transaktionen) und-Repositorys auszuführen domain-Logik
      • DTOs [OrderDTO, CustomerDTO]
    • Domain
      • Entitäten und Value Objects [Bestell -, Kunden -, LineItem-Adresse]
      • Repository-Schnittstellen [IOrderRepository, ICustomerRepository]
      • (optional) die Einheit der Arbeit-Interface [IUnitOfWork]
    • Infrastruktur.DataAccess (Mit ORM-oder Daten-Access-Technologie)
      • Repositories [OrderRepository, CustomerRepository]
      • (optional) die Einheit der Arbeit [UnitOfWork]
    • Infrastruktur.Gemeinsame
      • Protokollierung
      • Utilities

    Beispiel-Szenario:

    [Präsentation] OrderController:

     _orderService.CreateOrder(OrderDTO);

    [Anwendung] - OrderService:

     _unitOfWork.BeginTransaction();
 var customer = _customerRepository.GetById(orderDTO.CustomerId);
 var order = new Order() { Customer=customer, Price=orderDTO.Price, ... }
 _orderRepository.Add(order);
 _unitOfWork.Commit();

    Über Ihre Fragen:

    1) Ist die Offenlegung der Transaktion die Kontrolle zu MVC-eine gute Idee? Auf welcher Stufe sollte die Transaktion Kontrolle passieren? Mir scheint, dass MVC sollten nicht verantwortlich für Transaktionen, aber wie kann man das vermeiden?

    Nein, ich würde es vorziehen, zu trennen, die im application-layer, um zu erstellen, das design flexibel zu unterstützen, verschiedene Präsentationen.

    2) Sollte es werden einige automatische Weg, um Transaktionen? Das ActionFilter Umsetzung ist semi-automatisch, aber die transaction control ist eindeutig in der MVC-Abschnitt, der nicht der business-Schicht.

    Verwenden Transaktionen, die im application-layer.

    3) Ist das UnitOfWork-Klasse das gleiche wie ein business-Schicht-Klasse?
    - wenn dem so ist, bedeutet das, wir können fügen Sie benutzerdefinierte business-logic-Methoden in es?
    - wenn nicht, wickeln wir die Einheit der Arbeit mit einigen anderen Klasse(N) enthält, die business-logic-Methoden?

    Nein, es ist nur ein Weg, um Gruppen-tasks in die Geschäfte.
    Die business-Logik ist eigentlich gekapselt in Entitäten und wenn die Logik nicht in Beziehung zu einer Person umgesetzt werden sollten, domain-services [Flughafenuebertragungen.Transfer(account1, account2, Betrag)], für co-Ordinationen, Zugriff auf repositories, und Transaktionen der application layer ist der Platz.

    • 1). Ist die _unitOfWork in der [Anwendung] nur eine dünne Schicht für die Nhibernate-session? Warum nicht einfach eine Sitzung.BeginTransaction direkt? Gibt es etwas, transaction management, dass Sie tun innen unitOfWork? 2). Warum sind die DTO-Objekte notwendig? Können wir nicht einfach die Entitäten, abgebildet waren mit NHibernate der presentation layer? Was ist der Unterschied zu der DTO aus der NHibernate zugeordneten Entitäten? 3). Wie sollten wir uns die NHibernate session lifetime in dieses schema?
    • `UnitOfWork ist optional, wie gesagt, NHibernate session enthält die Logik für die Einheit der Arbeit und der Transaktion, aber es könnte abstrahiert werden, wenn Sie wollen, dass die Flexibilität des habens von mehr als Ausdauer-Technik. Sie könnten auch verwenden .Net verteilten Transaktion, wenn Sie wollen.
    • DTO Objekte sind notwendig, wenn Ihre Domäne-Objekte sind Komplex, und es ist mehr anpassbare Präsentation zum Beispiel in der Gestaltung von domain-Objekt, Um ein Objekt es könnte viele Attribute und Operationen (Methoden), die haben nichts zu tun mit der Präsentation, und konstruiert ein Komplexes Objekt-orientierten Art und Weise, für die Präsentation in der Regel benötigen Sie einen flach Daten-Objekte, optimiert für Präsentation und verbindlich.
    • Okay. Also, wie würden Sie behandeln NHibernate session lifetime? Da unsere presentation layer werden kann, MVC oder desktop-Benutzeroberfläche oder web-service, Benutzer-session-Leben kann unterschiedlich sein.
    • Mit IoC-container, die Sie anpassen können die Lebensdauer manager für die Sitzung basierend auf den AUFTRAGGEBER über, soweit es ist ein Web-Applikation (MVC), dann machen Sie es per http-request. wenn Sie Web-Dienst auch nach Wunsch, wenn es ist eine windows-Anwendung, dann kannst du es singleton ... das gute daran ist, dass man es nicht implementieren das lifecycle-management in alle Ihre Schichten, geben Sie einfach das IoC-container in der client-Schicht
    • Es sieht aus wie jemand, schnappen Sie sich Ihre Antwort und gebloggt habe, es als sein eigenes Werk fukyo-es.blogspot.com.br/2012/02/...

    InformationsquelleAutor Mohamed Abed
  2. 1

    Haben Sie schaute in die S#arp-Architektur? Es hat eine eingebaute MVC-Transaction handling -, Aktions-Filter.

    Ich bin in der Regel eine Schichtung Puristisch, so war ich nicht begeistern lassen MVC öffnen Sie die Sicht, aber ich bin gekommen, es zu mögen.

    Gibt es pro 's und con' s, aber hier sind einige Vorteile der Open Session In View pattern.:

    1. Lazy Loading -- Es vereinfacht Ihre Daten zugreifen, wenn Sie können, verlassen Sie sich auf lazy loading in MVC-Views. Keine Notwendigkeit, explizit beitreten, um alle erforderlichen Tabellen von der Ansicht. (Achten Sie darauf, um die N+1 problem durch den Beitritt ausdrücklich als lazy loading erzeugen würde, eine lächerliche Zahl von Anfragen. Data-grids sind eine gemeinsame Schuldige hier.)
    2. Einfacher STO-Ebene -- Ihre BSO nicht brauchen, um über Sitzungen. Es wird davon ausgegangen, dass Sie arbeiten bereits im Rahmen einer Sitzung.

    Wenn Sie nicht wollen, zu gehen, mit S#arp, können Sie noch implementieren, Open-Session-In-View-selbst mit nur ein paar Zeilen code in einem ActionFilter. Auf die Aktion Ausführen-Methode, die Sitzung eröffnen. In der action-Methode ausgeführt, commit, close und dispose. Dies ist, was wir tun, auf mein Projekt und es hat funktioniert gut für uns.

    • Also, Sie befürworten die Abwicklung von Transaktionen vollständig auf der MVC-Seite? Was sind die Nachteile? Was meinst du mit "ich war nicht aufgeregt über Vermietung MVC-Ansicht öffnen Sie das"? Meinten Sie "öffnen Sie die Sitzung"?
    • Ja, "öffnen Sie die Sicht" war ein Tippfehler. Einige Nachteile, nach meiner Erfahrung: 1. Lazy loading kann gesprächig sind-es wird mehr Anfragen, als Sie vielleicht benötigen, wenn Sie ausdrücklich bei allen Tabellen, die Sie brauchen würde. 2. Aus einer reinen Schichtung Sicht, es ist ein Verstoß gegen das Prinzip der Einzigen Verantwortung für die Präsentation öffnen einer Datenbank-Transaktion. Allerdings, meiner Erfahrung nach hat dies keine Probleme verursacht, wenn Ihr team ist senior genug, um zu verstehen, dass das öffnen der Sitzung ist die nur Datenbank-bezogene Aufgabe, die Präsentation übernimmt.
    • Also, um es zusammenzufassen, Sie raten zu einer einzigen Sitzung für das Leben der einzelnen http-session und Transaktion pro controller-Aktion?
    InformationsquelleAutor Thomas
  3. 0

    Das problem, das Sie mit jedem web-basierten app ist, dass es einige Kopplung der UI an die Geschäfts-Schicht durch die Notwendigkeit, Sie zu verwalten-Objekt-Lebenszeit durch die HTTP-Sitzung. In einer typischen desktop-Anwendung, die Sie nicht haben, um sorgen über die Sitzungen, so macht es leicht zu bewegen, alle Transaktions-handling weiter unten in der Kette.

    Überlegen, wo Sie wollen, um die Wiederverwendung der gleichen Logik in den drei apps, eine Web Site, ein Web-Service, und eine Desktop-Anwendung. Ohne daß die Handhabung der Transaktionen auf der präsentationsebene, es gibt keinen guten Weg, um mit der Transaktion verpflichtet, denn die business-Schicht ist unwissend, wie lange die Objekte existieren.

    So ist Ihre Wahl, entweder stellen Sie sicher, dass Sie verpflichten sich, alles in jeder Methode, Ihre Business-Objekte oder setzen Sie die Transaktion auf die UI.

    Eine Dritte alternative wäre der Aufbau einer Recht komplexen session-management-controller, die ich don ' T sogar wollen, zu denken... Das session-management-controller gekoppelt werden können, um die Benutzeroberfläche und die business-Logik, trennen Sie zum Teil.. das würde Aber erfordern viel mehr Analyse.

    • Ich denke, ich mag zu Begehen, alles, was in der business-Objekte, aber ich würde gerne die Nachteile dieses Ansatzes. Was ist der trade-off?
    InformationsquelleAutor Erik Funkenbusch
Schreibe einen Kommentar