|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Data components design questionI'm new to .NET but have quite a long experience as OO developer. I've been reading lots of documentation in order to get started with the SDK. First I started with on-line documentation about ADO.NET and now I am actually using the Microsoft Patterns and Practices document "Designing Data Tier Components and Passing Data Through Tiers" as a guide to develop my Data Access Logic Components. This document, as well as others, states that in a distributed anvironment each DALC should manage the connection towards its own data store. My questions are: 1) So, is it correct that such an approach invalidates the idea of a global connection for the whole application (example: a single Connection class instance that can be passed to each DALC constructor in the application)? Or this is true just for distributed applications? Would it be better to use a distributed oriented approach if I want to build a scalable, reusable solution? 2) Should the DALC know everything about the data store type? I mean, imagine I want to build a helper class for my DALC which would incapsulate methods needed to provide the right type of objects (Sql/OracleCommand, Sql/OracleDataAdapter and so on) to the DALC in order to accomplish a multiple db platforms implementation? Then I should tell the DALC, at a certain point in its lifecycle, (let's assume during its creation/initialization => in its construcytor code) which type of data store should be used (Sql Server, Oracle etc.). In a traditional approach, this would usually be implemented as a property read from the client application registry or something like that, and passed to the the DALC constructor. Now, if the DALC does manage the connection on its own who tells it which data store type should be used? And how? Am I taking it wrong if I think to read this option from a config file placed into the DALC phisical location? Or, again, am I thinking it wrong as in a distributed environment a single DALC "hides" its data store to all the callers and then it can be fixed at complie time? Hope I pointed out my doubts, and thanks in advance for any answers. Cheers, baba. I recommend you take a look at my open source data component.
source / binaries: http://sourceforge.net/projects/xqs-data documentation: http://www.xquisoft.com/xqsdn/documentation/index.html Each data provider tracks it's own connection instance. All the data providers are accessible by the data manager, which is a singleton. Actually, accessibility is determined by if you have pooling on or not. get your provider in one of these ways: DataProvider provider = (DataProvider)DataManager.Providers.Default.GetNextInstance(); DataProvider provider = (DataProvider)DataManager.Providers[1].GetNextInstance(); DataProvider provider = (DataProvider)DataManager.Providers["NamedConnection1"].GetNextInstance(); then you can call your execute method provider.Execute(...) provider.ExecuteNonQuery(...) etc... then release the instance back to the pool provider.ReturnToPool(); the data providers support transactions, so you may want to pass a provider instance to a child method if it needs to save data in the same transaction as the parent class. Or as in this example, you want to share a transaction between two non-hierarchical objects. SaveOrder(Order order) { DataProvider dataProvider = DataManager.Providers.Default.GetNextInstance(); try { dataProvider.BeginTransaction(); OrderFactory oFac = new OrderFactory(dataProvider); oFac.SaveOrder(order); OrderItemFactory oiFac = new OrderItemFactory(dataProvider) oiFac.SaveOrderItems(order.Items); dataProvider.CommitTransaction(); } catch (Exception) { dataProvider.RollbackTransaction(); // handle or throw exception } finally { dataProvider.ReturnToPool(); } } If pooling was off in this scenario, and another thread tried to use the default data provider at the same time, you would get an exception. When pooling on, you don't have to worry about the threading issue, since each caller that GetNextInstance() will have a reference to a different connection instance. however, when you put it back in the pool, it can be reused by another caller. With pooling on, and in a single thread scenario, you would only have one connection instance (if pool size was 1). Note that a web scenario should always be considered multi-threaded since each visitor's request is processed on a different thread. Win forms is single thread unless you (or a component you use) creates threads manually. there are more examples in the documentation. Michael Lang XQuiSoft LLC http://www.xquisoft.com/ |
|||||||||||||||||||||||