Wie streng folgen Sie der n-Tier-Architektur und Trennung von Bereichen zwischen den Schichten in Ihren Projekten?

Question

Ich nehme an die meisten Entwickler haben eine Idee von Multi-Layer-Architektur. Wir haben DAL (Data Access Layer), haben wir BLL (Business-Logik-Schicht) und irgendwo in der Nähe des Ende der Straße haben wir unsere UI. Wenn Sie ein Projekt haben, das irgendwie diese Prinzipien folgt, halten Sie (oder zumindest versuchen) zu halten / die Dinge gebracht, wo sie vom Konzept her gehören? Ich bin besonders interessiert in großen Unternehmen Anwendungen, bei denen Sie zusammen mit den Menschen viele andere arbeiten. Offensichtlich können Sie tun, was Sie mit Ihrem privaten Spielzeug Projekt wollen, erfinden jede Art einer Architektur und auch daran halten. Es ist nicht so einfach, mit großen Projekten, bei denen viele Menschen auf die Software oder Gesamt Chaos beigetragen.

Zum Beispiel habe ich zufällig Dinge wie UI-Komponenten sehen direkt auf die Datenbank gehen, um etwas „fehlt“ zusätzliche Daten zu holen, die BL nicht liefert, auch beide UI und BL arbeiten mit niedrigen Level-Elementen wie Tabellenfelder, wo meiner Meinung nach sie sollten nämlich DAL diese Vorgänge auf die untere Ebene delegieren. Es war besonders traurig, wenn nach den Dinge mit dem Senior-Entwickler Guy diskutiert ich sah er kein Problem damit überhaupt gesehen hat.

Wir können mich natürlich annehmen, und wer auch immer meinen Standpunkt teilt sind nur Perfektionisten zu sein, aber ich sah deutlich eine sehr disadvantegous Folge, dass es dauerte längere Zeit in einigen meiner Aufgaben alle „parallel“ zu verfolgen Routen, die die Daten zu und von der Datenbank fahren, und wer auch immer und in welcher Art und Weise jetzt zu identifizieren kann durch die neue Funktionalität beeinträchtigt wird I umgesetzt. So wie ich es sehe, sind diese Weiterentwicklung / Wartungskosten erhöhen einige Einsparungen übergewichten, wenn jemand schnell beschlossen, das Zeug zu hacken und die Aufgabe so schnell wie möglich zu schließen.

Sind Sie Projekte „rein“ oder sie verlassen die Idee vor, die klare Linie zwischen den Schichten eine lange Zeit zu halten? Wenn Sie noch es richtig zu halten, wie geht man mit den Kollegen, die diese Dinge nicht verstehen oder kümmern sich nicht um sie nur den Aufbau „custom“ Lösungen und Hacking-Hacks die ganze Zeit? Oder irgendwann in der Zeit gestoppt Sie mit der Windmühle zu kämpfen und nahm es als Strafe ?. EDIT: Etwas überrascht, dass nicht viele Leute haben sich für das Problem. Ist das die Zeichen der meisten ist es egal?

Answer 1

Je komplizierter unsere Anwendung wird, desto wichtige Trennung von Bedenken.

Bei 100 klocs waren die Anwendung ein großer Klecks, wie viele Geschäft Code in Formularklassen als anderswo und ruft in Form Methoden aus den Business-Klassen. Mit viel Heulen und Zähneknirschen, trennten wir die Geschäftslogik von der Anzeigelogik aus. Jede Klasse, die den Benutzer über den Fortschritt informieren erforderlich angehoben ein Ereignis, das durch die UI versenkt wurde. Und für eine Weile war alles richtig mit der Welt.

Rund 200 klocs, haben wir eine Datenschicht. Die Architektur unserer Anwendung war so, dass die meisten unserer Daten so schnell verarbeitet wurden, wie es in und sofort verworfen kam. Die meisten Konfigurationsinformationen in der Anwendung von Drittanbietern gespeichert, mit denen wir eine symbiotischen Beziehung geteilt. Aber Starteinstellungen wurden in allen möglichen ungeraden Ecken zu akkumulieren. Wir haben dann mit drei Konfigurationsmanagementsysteme auf, auf komplizierte Weise in die Business-Logik gewebt. Mit einem umfangreichen Rewrite konnten wir die Konfigurationsinformationen in eine eigenen Ebene trennen und den Umgang mit dem Streaming-Daten in einer anderen Schicht.

In der Nähe der 250 kloc Linie haben wir beschlossen, unsere Beziehung mit dem Drittanbieter zu beenden und unsere Anwendung allein stehen lassen. Wir begannen eine massive Rewrite und zum ersten Mal, eine aktuelle Datenbank zu unserer Anwendung hinzugefügt. Weil wir klare Linien zwischen Streaming-Information, Datenspeicherung und Business-Logik hatten, war dies eine ziemlich nahtlose Integration.

Nun, nähert sich 500 klocs, sind wir die Anwendung auf einem Raster-basierte Architektur zu bewegen. Nicht nur wird die Benutzeroberfläche von der Geschäftslogik auf einem anderen Computer getrennt werden, die tatsächliche Berechnung der Angebote und Aufträge, die die Anwendung sendet seine Last verteilt und verteilen die Effizienz zu maximieren. Dies würde ohne n-Tier-Architektur unmöglich sein.

In jeder Phase des Wachstums wurden wir entweder durch eine saubere Trennung Aided oder durch eigene Wirrwarr der Kommunikation behindert, Daten, Unternehmen und UI. Es hat wahrscheinlich eine wichtige Sorge als diese Trennung in der Schaffung dieser Anwendung nicht gewesen.

Answer 2

Das ist eine große Frage! Etwas jeder ASP.Net Entwickler braucht, um darüber nachzudenken. Sie werden wahrscheinlich eine Menge Antworten bekommen, würde ich diese grundlegenden gesunden Menschenverstand Ideen fördern.

- Betrachten wir der Einfachheit und Schnelligkeit der Lieferung als Teil einer „erfolgreichen“ Architektur, nicht nur „Reinheit“. Versuchen Sie, zwischen halten zu architektonischen Ideale zu balancieren, und praktisch.

- Im Allgemeinen scheint es sinnvoll zu sein, den Code aus in Schichten zu unterteilen, wie Sie erwähnen. Ich würde vorschlagen, obwohl das für seitenspezifische Logik, könnte es auf der Seite gelassen werden, wenn es einfacher / schneller - warum generische Geschäftsobjekte für Code erstellen, die nur an einem Ort verwendet wird. Wie es ist gesagt worden, „Vorzeitige Optimierung ist die Wurzel allen Übels ist.“.

-. Halten Sie die Schichten und die Komplexität auf ein Minimum Kodierungszeit zu reduzieren und verbessern die Lesbarkeit und Wartbarkeit

Es gibt viele Puristen auf dieser Seite, die Architektur für die Website-Architektur zu tun - verwendet Architektur als Werkzeug eine Lösung für ein geschäftliches Problem zu liefern, nicht nur als eine Kunstform für seine selbst willen, lassen Sie es sein, nützliches Werkzeug, anstatt es Sie verwenden.

Answer 3

Halten Sie die Bedenken seperate. Es ist sehr, sehr wichtig. Nicht UI mit Biz und Biz mit Datenschicht mischen. Die Arbeit mit Abstraktion. Arbeiten mit Abstraktion macht auch die Prüfung (Unit-Tests) leichter (Mock sie). Ich halte streng jede Schicht, wo sie hingehört. Denken Sie daran, dass die höchst Kosten in jedem Projekt Wartung es ist. Wenn Sie die Sorgen mischen dann würde Wartung zu einem Alptraum werden.

Answer 4

Wir haben eine WinForms-Anwendung und eine ASP.NET-Anwendung. Beide benutzen das gleiche Business Objects-Projekt (etwa 140 Klassen).

Das WinForms-Projekt besteht aus etwa 350 Form und Benutzersteuerklassen, und sehr wenige (<10) davon müssen Metadaten über sich selbst aus der Datenbank.

Das ASP.NET-Projekt hat etwa 100 ASPX-Seiten.

Wir haben eine Datenzugriffsschicht, bestehend aus 5 Klassen, die sich mit ADO.NET, Fäden und Transaktionen. Sie wandeln Anforderungen von dem Business Objects in SQL Server Anrufe.

Die UI-Schichten (mit Ausnahme der wenigen Klassen, die Metadaten über Form benötigen Sizing) tun überhaupt keinen Zugriff auf die Datenbank. Auch gehen die wenigen Ausnahmen durch die DAL wie alles andere.

Die Business-Schicht weiß nichts über die internen Abläufe der Datenzugriffsschicht, und wenn sie Daten benötigt, immer nur öffentliche Methoden auf den DAL-Klassen aufruft.

Ich bin nicht eine fundamentalistische, wenn es um diese Art der Sache kommt, aber wir haben nie auf diesen einen schneiden Ecken benötigt.

Also kurz gesagt, 100% rein. Es ist einfach immer besser ausgearbeitet, es richtig zu tun.

Wir würden eine Hölle von einem guten Grund haben müssen jetzt weg von diesem zu bewegen.

Answer 5

Code Monkeys und Puristen sind viel wie jede andere extremistische im Leben.

Wir haben äußersten rechten Flügel und äußersten linken Flügel. Nur sehr wenige Menschen sind genau das eine oder das andere, und sie finden einen guten Mittelweg, wo sie sitzen. Wenn es nicht für die Extremisten war würden wir nicht wissen, wo die Grenzen liegen.

Was die Art, wie ich Code geht. Ich höre die Puristen Art und Weise, es zu tun. Ich sehe den Code Affen über ihre Methoden gehen. Ich benutze meine Erfahrung, einen Mittelweg zu wählen, die mir die richtige Menge an Flexibilität und Verwaltbarkeit zusammen mit der Zeit, die ich und die Menge des Geldes zu produzieren brauchen gibt, denn ich werde tatsächlich bekommen, es zu tun.

Answer 6

Je größer der Code, desto länger die Lebensdauer, desto mehr verschiedene Menschen arbeiten auf dem Code (beide gleichzeitig oder während der Laufzeit) desto wichtiger sie Trennung in Schichten ist. Am Anfang scheint es ein bisschen mehr unnötige Arbeit zu sein, aber auf lange Sicht lohnt es sich mehrfach.

Wie für die Trennung der Durchsetzung: Das ist, warum Ihr leitender Programmierer oder technischer Architekt gute Soft Skills benötigt sowie rein technische Fähigkeiten. Sie können versuchen, die Trennung technisch (siehe unten), aber am Ende zu erzwingen, müssen Sie (oder coerce) Ihre Entwickler davon zu überzeugen, sauber, das große Bild zu halten.

Aber das ist nicht zu sagen, dass technische Mittel, um die Trennung haben keine Verwendung zu erzwingen. In der Tat fand ich, dass sichergestellt wird, dass „grenzüberschreitende Anrufe“ etwas schwierig zu machen wird die Menschen verbringen mehr Zeit darüber nachzudenken, was sie wirklich brauchen, in der grenzüberschreitenden-Schnittstelle machen, saubere Schnittstellen führen. Dabei spielt es keine Rolle, ob die Schwierigkeit, technisch ist (weil Sie COM oder CORBA verwenden) oder etwas anderes (Sie haben ein 7 Seite Formular in dreifacher Ausfertigung auszufüllen).