Gibt es einen Grund, warum ich nicht eine ältere Version von Data Access Application Block (Sqlhelper) zusammen mit Enterprise Library verwenden kann (wenn ich nicht die Datenteile davon verwenden?)mit älteren Data Access Application Block neben der neueren Enterprise Library
EnterpriseLibrary ist in mehrere DLLs unterteilt, so dass Sie nicht einmal die Teile referenzieren müssen, die Sie nicht möchten. Selbst wenn sie referenziert werden, gibt es nichts, was Sie daran hindert, zu mischen und zu vergleichen.
Wenn Fälle auftreten, in denen mehrere Klassen mit demselben Namen in derselben Klasse referenziert werden, benennen Sie sie explizit (oder über eine using-Anweisung), um sicherzustellen, dass Sie den richtigen Objekttyp verwenden.
Denken Sie daran, dass der vollqualifizierte Name eines Objekts seinen Namespace enthält. Daher ist SqlHelper in einem nicht identisch mit SqlHelper in dem anderen, solange Sie den Namespace einschließen.
Viel Spaß!
Ich sehe nicht, warum Sie es technisch nicht tun können. Aber es scheint seltsam, dass Sie es nicht konvertieren möchten.
Die "Sauberkeit" des EnterpriseLibarary.Data-Frameworks ist sehr ansprechend.
Es macht auch sehr "sauberen" Code. Beispiel:
public override IDataReader CustomersGetSingleWithOrdersReader(string customerId)
{
IDataReader returnReader = null;
try
{
Database db = this.GetDatabase(); //encapsulate call to retrieve a database object, very simple routine
DbCommand dbc = db.GetStoredProcCommand ("dbo.uspCustomersGetSingleWithOrders);
db.AddInParameter(dbc, "@CustomerID", System.Data.DbType.String, customerId);
returnReader = db.ExecuteReader(dbc);
return returnReader;
}
finally
{
}
}
Sie etwa 2 Dinge im obigen Code kümmern. Welche gespeicherte Prozedur wird aufgerufen? Welche Parameter zu geben. Die EnterpriseLibrary.Data erledigt den Rest für Sie.
Aus meiner Erfahrung, das einzige, was die EnterpriseLibrary.Data kann man nicht schützen aus (denn es kann nicht in dieser Situation) wird unter Verwendung eines IDataReader UND ES DANN NICHT ZUM ABSCHLUSS. Das ist ein großes No-No.
Aber wie bereits erwähnt, werden vollständig qualifizierte Namespaces und solche Sie um das Problem zu bekommen.
Vergessen Sie nicht, dass das EnterpriseLibrary.Data Framework ausgereifter ist als das ursprüngliche DAAB.
Und vergessen Sie nicht einen der Fehler auf DAAB 2.0.
http://weblogs.asp.net/rosherove/archive/2003/07/29/10614.aspx