MVC3 Design - Repository-Muster und Services Layer [geschlossen]

In der geschichteten Anwendungsarchitektur gibt es eine grundlegende Regel, die besagt, dass Sie niemals eine Ebene umgehen . Wenn Sie Ihr Repository direkt von Ihrem Controller abfragen, verletzen Sie diese Regel.

Na und? können Sie sagen. Was ist, wenn die Serviceebene keinen Wert hinzufügt? Nun, vielleicht in der Zukunft ...

Sie können wählen, die Regel zu brechen, aber dann wäre es keine mehrschichtige Anwendung mehr . Das mag auch okay sein - es gibt andere gute (noch bessere) Anwendungsarchitekturen, aber ich denke, dass Sie zuerst eine Entscheidung bezüglich der Gesamtarchitektur treffen sollten und dann bei dieser Entscheidung bleiben . Andernfalls erhalten Sie den Spaghetti-Code - wir nennen ihn Lasagne , wenn es sich um eine geschichtete Anwendung handelt:)

Es kommt darauf an. Wenn Sie in Zukunft komplexe Geschäftsregeln haben möchten, würde ich die Serviceebene hinzufügen. Wenn Ihre Site nur CRUD-Vorgänge mit wenig oder keiner Logik in der Serviceschicht ausführt, können Sie sie direkt als Repository-Ebene bezeichnen.

  

Soll ein Controller Entitäten über das Repository-Muster abrufen oder Daten von der Services-Schicht abrufen?

Idealerweise sollte der Controller nur die Service-Schicht verwenden, die selbst von einem oder mehreren Repositories abhängt, um eine oder mehrere einfache CRUD-Operationen zu einer Geschäftsoperation zusammenzufassen. Es gibt jedoch Fälle in einfachen Anwendungen, in denen Sie möglicherweise keine Service-Schicht benötigen und der Controller direkt ein Repository verwenden muss.

Es ist immer eine Frage, was zu dir passt und was dein Stil ist. Für mich bevorzuge ich den Zugriff auf die Serviceebene von der Controller-Aktion. Der Service greift dann auf das Repository-Modell zu.