Um Datenbankverbindung in Geschäftsobjekten einzukapseln oder nicht?

Question

Normalerweise möchte ich die Datenbankverbindung selbst erstellen und ihre Lebensdauer manuell mit `using {} 'steuern. Zum Beispiel:

SqlConnection sqlConnection = new SqlConnection(connectionString); 
using(sqlConnection) { 
    BusinessObject myBusinessObject = new BusinessObject(sqlConnection); 
    // do stuff with the business object 
    ... 
} 

So ist es sichtbar und offensichtlich, dass ich eine Ressource verwende, die entsprechend aufgeräumt werden muss. Dies führt jedoch zu einer Menge sich wiederholender Anstrengungen. Ich bin versucht, die SQL-Verbindung innerhalb des Geschäftsobjekts zu erstellen und IDisposable darauf zu implementieren. Ich würde die Verbindung in der Dispose() Methode schließen.

using(BusinessObject myBusinessObject = new BusinessObject()) { 
    // do stuff with myBusinessObject 
    ... 
} 

Das Problem, das ich habe ist, dass es nicht so offensichtlich sein könnte, dass das Business-Objekt entsorgt werden muss, wenn Sie es im Einsatz zu sehen.

Wie würdest du es tun?

Answer 1

Geschäftsobjekte sollten in Bezug auf die Datenbank vernünftig (oder vollständig) dumm sein. Sie sollten eine Art von Zugriffsebenenobjekt (Repository oder Datenkontext) implementieren, das weiß, wie Sie Ihre Geschäftsobjekte in der Datenbank beibehalten und die Verbindungslogik beibehalten, anstatt den Code in jedes Ihrer Geschäftsobjekte zu schreiben. Ihr Repository oder Kontext wäre wegwerfbar, so dass es nach sich selbst aufräumen könnte. @ Marcs Vorschlag, dass Sie dem Muster der Arbeitseinheit folgen, ist ein guter Vorschlag.

Sie könnten LINQtoSQL, nHibernate, Subsonic, etc. verwenden, um sie zu verwenden oder zumindest für Ideen, wie man eine gute Datenschicht strukturiert, wenn Sie darauf bestehen, Ihre eigenen zu schreiben. Aus persönlicher Erfahrung kann ich Ihnen sagen, dass die Verwendung einer vorhandenen Technologie viel einfacher ist als das Schreiben und Verwalten Ihrer eigenen Technologie.

Answer 2

Nun, zuerst würde ich Verbindungen zum Repository verlassen.

Zweitens würde ich nicht eine Verbindung auf einem Objekt hängen bleiben - ich würde es nur für eine Einheit der Arbeit (d. H. Eine einzige Methode) verwenden. Die Chancen stehen gut, dass Sie (aufgrund von Pooling) die gleiche physische Verbindung trotzdem erhalten. Das System ist schon lange im Umgang mit solchen Dingen, so dass Sie es nicht müssen.

Der schwierigere Fall ist Transaktionen, wo TransactionScope ist viel einfacher als die Übergabe eines DB-Transaktionsobjekts herum.

Answer 3

Ich glaube nicht, dass ein Geschäftsobjekt wissen oder sich darum kümmern sollte, ob es hartnäckig ist oder nicht. Ein einzelnes persistentes Geschäftsobjekt kann nicht wissen, wann es Teil einer größeren Arbeitseinheit ist. Das ist die Verantwortung der Serviceebene. Lassen Sie die Verbindung aus den Business-Objekten heraus. Die Service-Schicht ist der richtige Ort, um Verbindungen zu erhalten, in der Regel aus einem Verbindungspool, Transaktionsgrenzen festlegen, Commit oder Rollback und Bereinigung.