Gibt es negative Gründe für den Einsatz einer N-Tier-Lösung?

Question

Ich bin ziemlich neu in meinem Unternehmen (2 Wochen) und wir starten eine neue Plattform für unser System mit .NET 3.5 Team Foundation von DotNetNuke.Unser „Architekt“ schlägt vor, ein Klassenprojekt zu verwenden.Natürlich schließe ich mich einer „3-stufigen“ Architektur an (Projekte der Business-, Daten- und Web-Klasse).

Gibt es irgendwelche Nachteile bei der Verwendung dieser Architektur?Vorteile wären die Trennung von Code und Daten, das Halten von Klassenobjekten von Ihrem Code usw.

Answer 1

Ich denke, ein ziemlich großer Nachteil besteht darin, dass das zusätzliche Codevolumen, das Sie für einen schreiben, verwalten und warten müssen klein Das Projekt könnte einfach übertrieben sein.

Es kommt darauf an, was für die Größe des Projekts, die voraussichtliche Laufzeit des endgültigen Projekts und das Budget angemessen ist!Manchmal ist es zwar verlockend, Dinge „richtig“ zu machen, aber etwas „Leichteres“ zu tun, kann die richtige kommerzielle Entscheidung sein!

Answer 2

Ein unerfahrenes Team braucht tendenziell länger, um ein 3-Tier-System zu erstellen. Es ist mehr Code, also mehr Fehler.Ich spiele allerdings nur den Advokaten des Teufels.

Answer 3

Ich würde mich stark für den N-stufigen Ansatz einsetzen, selbst wenn es sich um ein kleines Projekt handelt.Wenn Sie ein ORM-Tool wie codesmith + nettiers verwenden, können Sie die Projekte schnell einrichten und Code entwickeln, der Ihre Geschäftsprobleme schnell löst.

Es bringt mich um, wenn man ein neues Projekt startet und tagelang am Spinnrad sitzt und darüber redet, wie die „Architektur“ aussehen sollte.Sie möchten Ihre Zeit damit verbringen, das Geschäftsproblem zu lösen, und nicht damit, Probleme zu lösen, die andere Leute für Sie gelöst haben.Die Verwendung eines ORM (es spielt keine Rolle, welches, wählen Sie einfach eines aus und bleiben Sie dabei) hilft Ihnen dabei, sich zunächst auf die Ziele des Projekts zu konzentrieren und wird nicht von der Lösung von „Architektur“-Problemen abgelenkt.

Wenn der Architekt am Ende des Tages den Ein-Projekt-Ansatz verfolgen möchte, gibt es keinen Grund, warum Sie nicht vorerst einen Ordner „app_code“ mit einem BLL- und einem DAL-Ordner erstellen können, um den Code zu trennen, was Ihnen den Übergang zu einem erleichtert N-Tier-Lösung später.

Answer 4

Weil du das willst Fähigkeit Um die Schichten auf verschiedene physische Ebenen verteilen zu können (ich verwende immer „Tier“ für physisch und „Schicht“ für logisch), sollten Sie es sich zweimal überlegen, bevor Sie einfach alles in eine Klasse packen, da Sie in diesem Fall größere Umgestaltungen durchführen müssen oder wenn Sie mit der Verteilung beginnen müssen.

Answer 5

Wie bei allem schafft Abstraktion Komplexität, und daher sollte die Komplexität der Umsetzung von N-Stufen ordnungsgemäß begründet werden. Beispielsweise: Bringt N-Stufen tatsächlich Vorteile für das System?Dort Wille Es handelt sich um kleine Systeme, die am besten mit N-Tier funktionieren, obwohl dies bei vielen nicht der Fall ist.

Auch wenn Ihr System derzeit klein ist, möchten Sie es möglicherweise später um weitere Funktionen erweitern und nicht auf N-Ebenen umsteigen könnte stellen für Sie eine Art technische Schuld dar, Sie müssen also vorsichtig sein.

Answer 6

Der einzige Nachteil ist die Komplexität, aber wie schwierig ist es wirklich, einige Domänenobjekte hinzuzufügen und an eine Liste von ihnen zu binden, anstatt einen Datensatz zu verwenden?Sie müssen nicht einmal drei separate Projekte erstellen, Sie können einfach drei separate Ordner innerhalb der Web-App erstellen und jedem einen Namensraum zuweisen, z. B. YourCompany.YourApp.Domain, YourCompany.YourApp.Data usw.

Der große Vorteil liegt in der flexibleren Lösung.Wenn Sie beginnen, Ihre App als datenzentrierte Anwendung zu schreiben und Ihre Webformularseiten stark an Datensätze zu koppeln, werden Sie am Ende viel mehr Arbeit leisten und später zu einem stärker domänenzentrierten Modell migrieren, da Ihre Geschäftslogik immer komplexer wird.

Vielleicht konzentrieren Sie sich kurzfristig auf eine einfache Lösung, indem Sie sehr einfache Domänenobjekte erstellen und diese aus Datensätzen füllen. Anschließend können Sie ihnen nach Bedarf Geschäftslogik hinzufügen und bei Bedarf ein ausgefeilteres ORM erstellen oder nhibernate verwenden.