ASP.Net 2.0 Anwendung ohne Business Logic Layer?

Question

Ist es "akzeptabel", eine ASP.Net 2.0 Anwendung ohne den BLL (Business Logic Layer) wie folgt aussehen?

1. SQL Server Datenspeicherung und gespeicherte Prozeduren
2. Data Link Layer (Strongly Typed Table Adapters) mit Verbindung zu Stored Procs
3. Präsentationsschicht ASPX-Seiten mit Code dahinter und ObjectDataSource zur direkten Verbindung mit der DLL

Ist eine BLL immer vorzuziehen, auch wenn die Geschäftslogik im dahinter liegenden Code der Präsentation vollständig validierbar ist? Was sind die möglichen Nachteile, wenn keine BLL verwendet wird?

Answer 1

Das ist akzeptabel, solange man sich über die Konsequenzen im Klaren ist. Der Hauptgrund, warum Sie eine BLL haben, ist die Wiederverwendung dieser Logik an anderer Stelle in Ihrer Anwendung.

Wenn Sie die gesamte Validierungslogik im Präsentationscode haben, erschweren Sie die Wiederverwendung an anderer Stelle in Ihrer Anwendung.

Answer 2

Wie alles andere ist sie umweltabhängig und hängt von der Nutzung des Systems ab. Die Frage, die Sie sich stellen müssen, lautet:

1. Wird dies aktiv entwickelt werden
2. Wird dies über viele Jahre hinweg genutzt und weiter ausgebaut?
3. Ist die Ausdehnung der Anwendung unbekannt und somit unendlich?

In Wirklichkeit geht es um Faulheit. Wie viel Zeit wollen Sie damit verbringen, das System von der Benutzeroberfläche aus zu überarbeiten? Da keine Geschäftsebene vorhanden ist, bedeutet dies eine Verdoppelung der Regeln in der Benutzeroberfläche über viele, viele Seiten hinweg.

Dann wieder, wenn es sich um eine Machbarkeitsstudie, eine kurze Demo oder ein Klassenprojekt handelt. Nehmen Sie den einfachen Weg.

Answer 3

Annehmbar? Das hängt davon ab, wen Sie fragen und welche Anforderungen Sie haben. Handelt es sich um eine interne Anwendung, die nur von Ihnen und ein paar anderen Personen genutzt wird? Vielleicht ist das gut genug. Wenn es sich um eine produktionsreife Unternehmensanwendung handelt, die im Laufe der Jahre wachsen und gewartet werden soll, dann sollten Sie wahrscheinlich im Vorfeld mehr Aufwand betreiben, um eine wartbare Anwendung zu erstellen.

Separation of Concerns ist eine wichtige Designtechnik für die Entwicklung wartbarer Anwendungen. Wenn Sie Präsentations-, Geschäfts- und Datenzugriffslogik miteinander vermischen, kann dies zu einer sehr anfälligen, schwer zu ändernden Anwendungsarchitektur führen.

Answer 4

Das kommt darauf an. Wenn sich Ihre Geschäftslogik in Ihren Klick-Ereignissen und Seitenladevorgängen befindet, ist dies NICHT akzeptabel.

Es scheint, dass Ihre Geschäftslogik irgendwo innerhalb der DAL (z. B. gespeicherte Prozeduren und so), nur so lange, wie Sie konsistent sind, ist es in Ordnung. Solange Sie sehr, sehr sicher sind, dass Ihre Kunden siempre SQL Server verwenden, ist dieser Ansatz kein Problem.

Ich kenne einen Kollegen, der todo seine Geschäftslogik in gespeicherten Prozeduren, dass seine Ansichten größtenteils Thin-Clients für Datenbank-Backends sind: Er ist mit dem Produkt, das er verkauft, ungeheuer erfolgreich. Das liegt aber nur daran, dass er sehr konsequent damit ist.

Answer 5

Wenn es sich um eine allgemeine Anwendung handelt, kann die Geschäftslogikschicht auch in völlig anderen Anwendungen verwendet werden. So verwende ich normalerweise meine CMS-bezogenen BLL-Klassen in anderen Anwendungen.