Last week i was exploring on some of the design aspects with respect to the Data Access Layer.
Here goes the observation and findings of those analysis...
1) For instance if i have to design a Data access layer ,where in i have to deal with Customers, Products and Customer orders. ie. One customer can place many orders and one order can have many products.
For the above case, one approach could be to have a single big file repesenting the Data Access Layer, but if we go with this approach you will end up in
1) maintenance issue
2) It is tough to handle transactions, if we go bigger. ie. if we want to go ahead with multitier deployment ,where to handle transaction ? becomes an issue , since all the code blocks of entities will be there in one single data access layer.
Hence the suggestion would be to have multiple data access components. for instance for the above case, we should have 3 data access components.
1) customer data access
3) Order data access.
if we follow this approach , ultimatley all the things will fall in place quite easily or unknowingly.
ie if we want to achieve any functionality where in 3 components has to execute together, then you will end up writing a Business processing component on top of these 3 calls and eventually this component will be inside the Business layer and it becomes the root for the transaction.....
I hope this helps.