Common Data Access Layer

Topics: Web Client Software Factory
Jan 25, 2007 at 3:21 AM

How can i create a Foundation Module containing a Data Access Layer Common to all Business Modules in my solution, in a way that any business module may access any data entity in the DAL.


Business Modules:


Foundation Module:

DAL (Containing all Entities)

In a real world application General Ledger, Accounts Payable, Accounts Receivable all may use the Chart Of Account Entities.

Thanks in Advance.
Jan 25, 2007 at 8:30 AM
You should be able to achieve this just by adding a reference to the Foundational Module project to all the Business Module projects... a foundational module is pretty much a standard class library so there shouldn't be an issue here.

However, you might like to consider mediating comms between the business modules and the data access layer - for example, do you want your presenters to directly call data access code?

The Service pattern works well for this - having a GeneralLedgerDataService might be a good choice, for example.

All depends on the rest of your app I suppose!

Does that answer your question sufficiently?

Jan 26, 2007 at 3:25 PM

If I where you I would write the BusinessEntities in a different assembly
then the DAL.

Jan 26, 2007 at 9:40 PM
jchompff has a good suggestion, which is how I would do it.
Jan 27, 2007 at 10:25 AM
I mostly agree with you... my answer was based on "how would I" more than "should I", but this raises an interesting question that might be useful for inclusion in the factory guidance; how do the factory's patterns affect the recommended application architecture diagram? See picture here - figure 1.0.

I would argue for the most part that it doesn't; the factory covers primarily the UI & UI Process Component sections... the reality of how business logic and entities are then implemented isn't changed - it's up to you according to how you used to do it.

However, there is an argument that a slightly different architecture would make sense for Service Oriented applications - for example, using the "Services" pattern for Service Agents might make use of a Controller but no further local business logic - it is all hosted remotely.

Anyone else got thoughts on this?

Jan 22, 2008 at 10:20 PM

I recommend the following practices as they will result in better handling of data access code. I have architect ed couple of web clients using Web Client Software Factory and found this approach very rewarding.

1. Create a foundation module: a very thin wrapper on top of Enterprise Library's Data Access block. You can always later add any custom code in this module that might not come with the block like locking mechanisms, transactions etc.

2. Use the service pattern and have data services like GLDataService, APDataService, etc to access the database via the common database foundation module.

3. Limit access of these data services to only the application controllers and not the presenters.

Please let me know if this works and if you need any more help.

It might be a good idea for some of us here to put together some best practices for web client software factory. A 2-3 page document on standards will be nice for the community. I can work with patterns and practices group or anyone to come up with this.

I am very sure, people will start asking about other concepts like exception handling, logging etc...

Feb 6, 2008 at 9:18 AM
Hey RouteCoder

I have realised the need for LTM Transactions within the Web Client Software Factory generated code and I am not so sure of how to progress. Your strp 1. looks very intersting, but where to start ? could you point me at any further reading ?

Mar 26, 2008 at 4:27 PM
Hi Steve,

Please elaborate more on your LTM Transactions? Did you create a foundation module for your Data Services that you can use in all business modules?

A note: Your controller is the one that needs to control all the transactions. Data Services are merely data calls / wrappers over stored procedures. Controller decides based on business or other logic to commit or rollback these transactions.
Dec 3, 2008 at 1:11 AM
Edited Dec 3, 2008 at 4:17 AM
I am thinking about the DAL for my first WCSF app. and your suggestions are very useful here. How did you manage dependency injection in your case? I expect to have around 8-10 different DataServices (or Data Access objects of some kind) and I want access to be limited to the module controller as you suggest in #3. Clearly, constructor injection would be the wrong choice here but if I use injection attributes on public properties, then I'm exposing DataServices to any presenters that have a reference to the module controller.

any thoughts?