Wo die Geschäftslogik zu bewegen, wenn es aus der Datenbank zu bewegen

Question

Ich habe eine CRUD-schwere ASP.NET-Anwendung mit allen Business-Logik in Stored Procedures.

Als Beispiel gibt es ein Verfahren UPDATE gespeichert, die ~ 500 Zeilen lang sind und enthalten große Mengen an bedingter Logik, Referenzierung mehr Tabellen & UDF. Das proc nimmt im Feldnamen aktualisiert und den neuen Wert setzt eine Reihe von deklarierten Variablen, hat eine Reihe von Validierungs- und erzeugt eine dynamische SQL-Anweisung, das Update zu tun. Sobald Größe passt alle. Es ist groß und unübersichtlich.

Ich mag die Business-Logik über zu .NET Seite bewegen es leichter zu verwalten / aktualisieren, zu testen und unter Quellcodeverwaltung gestellt.

Meine Frage ist: Wo sollte diese Geschäftslogik gehen?

Sagen wir, ich habe ein PurchaseOrder Objekt mit einer Eigenschaft namens ‚Factory‘. Wenn die Fabrik wird geändert, muss ich sicher zugewiesen die neue Fabrik machen das Produkt macht, die auf dem PurchaseOrder ist, dass es Preisgestaltung hat, und dass es eine Mindestmenge Verlangte auf dieser Fabrik basiert, usw. Alle diese Validierungen erfordern Anfragen in der Datenbank.

Sollte habe ich die Fabrik Setter des PurchaseOrder Objekts für das Erledigen der Datenüberprüfung über eine ‚isFactoryValid‘ Methode / Eigenschaft verantwortlich sein, die mehrere Anrufe zu einem allgemeinen Datenzugriffsobjekt macht dann das Update, wenn es?

Oder muß ich ein PurchaseOrder / Datenbank ‚Proxy‘ Objekt erstellen, die für den Umgang mit verantwortlich sind nur PurchaseOrder bezogenen Datenzugriff. In diesem Fall würde ich eine ‚isFactoryValid‘ Methode in der Proxy, der von den PurchaseOrder des Setter und dann ein Aufruf an die Proxy der Update-Methode?

genannt

Wie kann ich feststellen, ob ich über zunehmenden Verkehr auf die Datenbank mit allen diesen zusätzlichen Anrufen kümmern?

Answer 1

Es gibt zwei Hauptstrukturen, die weit verbreitet sind Persistenzlogik aus der DB zu implementieren:

• Active Record -. Persistenz-Logik ist in Ihrem Domain-Objekt
• Repository Pattern - Ein separates Objekt oder Schicht übernimmt den Datenzugriff - Ihre "proxy" -Konzept Adressen dies.

Der Trick mit den beiden Objekten ist zu wissen, wann eine Reise in die Datenbank zu machen und zu wissen, wann man nicht . Zum Beispiel gibt es wird redundante Validierungen, die zwischen der DB und der Domänenschicht, beispielsweise auch geschehen wird, bevor Sie eine DB Anruf sollten Sie keine Nullwerte auswerten, Kürzen von Zeichenfolgen auf Länge, etc. nach. Nur diese Kontrollen wurden ein Aufruf zum speichern in der db gemacht werden.

gemacht soll

Es gibt auch eine breite Palette von Strategien zur Verfügung, die Leistung zu erhöhen oder Datenbank Fahrten, wie verzögertes Laden, Transaktionen und dergleichen zu minimieren.

Answer 2

Eine Möglichkeit, dies zu tun: Sie haben eine Datenschicht in .net (einem oder Klasse mehr Daten) mit einer Schnittstelle für die Schicht ... dann Sie eine Business-Schicht haben, die die Business-Logik mit der Schnittstelle führt. http://en.wikipedia.org/wiki/Multitier_architecture

Answer 3

Sie können auch Ihre Geschäftslogik in Stücke von wieder verwendbaren Web-Services verwandeln. WCF bietet große Werkzeugunterstützung.

Answer 4

Schauen Sie in Domain Driven Design (DDD), die eine ganze Reihe von Fragen beantworten. Er spricht über Repositoryies für den Datenzugriff und die Spezifikation für Validierungen. Eine gute ORM würde auch helfen. Dieses Buch ist auch groß:

alt text http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7 .jpg

Answer 5

Dies wird auf dem Objektmodell ab, die Sie erstellt haben, und wie Sie Ihre Anrufer lassen habe entscheiden, welche Fabrik wird die neue Fabrik, die PurchaseOrder zu verarbeiten.

Zum Beispiel, wenn Sie Ihre Anrufer eine Liste von Fabriken geben sie auswählen können, können Sie die Liste nur diejenigen herauszufiltern, die das Produkt in Verbindung mit der bestehenden PurchaseOrder unterstützen (ich gehe davon sind Sie einen vorhandenen Auftrag bearbeitet) . Wenn Sie die PurchaseOrder haben möchten bestätigen, dass die Fabrik den Auftrag verarbeiten kann, hätte ich die Setter auf der PurchaseOrder auf der Fabrik eine Methode aufrufen (so etwas wie CanProcessOrderFor (Produkt, Menge)).

Ich gehe davon aus, dass Sie bereits eine Datenbankabfrage zu tun haben mußten die Liste der Fabriken und den PurchaseOrder zu bekommen. Ich würde die Abfrage hat für die Fabrikobjekte ihre Liste der unterstützten Produkte und aktueller Mengen zurückkehren (oder Mindestbestell - was auch immer Ihre Logik sein muss).

Eine gute ORM wie NHibernate lassen Sie einige dieser Ergebnisse zwischenzuspeichern Roundtrips zu minimieren, wenn dies ein gängiges Szenario ist.