Data Access Application Block 1

[jby1]

Hi

I am currently in the process of designing a system pretty much from scratch (will be developed in C#), with the exception of the database, which I do not have the liberty of redesigning at this moment. Hence I feel that it is particularily important to keep database code seperate from business logic and presentation logic, as well as having a clearly defined interface to all database access methods. That way if I get to redesign the database in the future it will have a minimal impact on the system.

I am trying to determine my approach to this problem. I am considering using a single static DatabaseGateway class, which defines all legal data access methods, and effectively delegates them to more specialized Data Access Objects (DAOs), which will be invisible to the rest of the application. I know this could lead to a rather unwieldy DatabaseGateway, but I feel this is worth it to retain control over the database interface.

I am also considering using Microsoft Data Access Application Block within my DAOs to handle the actual database access.

I have never before tried this approach, and while it seems fine to me in theory, I am wondering if anybody out there has any comment or can see something wrong that escapes me.

Thanks for any feedback!!

 

[palbano]

>> I am considering using a single static DatabaseGateway class

Using a Singleton as a Factory technique is a likely candidate. However the types of the created objects should be interfaces rather than a single concrete class. In a large application there could be 1 … of these interfaces dividing the database layer into some domain specific and logical areas.


-pete

 

[jby1]

So are you suggesting that I use a Singleton Factory class as my entry point to the database layer, which then returns one of a number of interfaces to database access objects? Would this not require knowledge of the internal database layer being coded into the business logic? Or am I missing something here?

 

[jfrost10]

Microsoft has a great resource available that describes their recommendation as to how to architect/program a data access layer (which does suggest using the data access block you mentioned, or a similar idea of one that you would code yourself).

In their example though, the data access layer is the last thing before the database. it holds all the generic functions that you'd need. For instance, I coded my own Data Access Tier object, which just had functions that would take in a command object, but would either return a datatable, or a scaler, or execute non query, etc. Thats all the data access block should do.

Now, on TOP of that is your Data Access Components

 

[jfrost10]

Microsoft has a great resource available that describes their recommendation as to how to architect/program a data access layer (which does suggest using the data access block you mentioned, or a similar idea of one that you would code yourself).

In their example though, the data access layer is the last thing before the database. it holds all the generic functions that you'd need. For instance, I coded my own Data Access Tier object, which just had functions that would take in a command object, but would either return a datatable, or a scaler, or execute non query, etc. Thats all the data access block should do.

Now, on TOP of that is your Data Access Components

(sorry if this got posted unfinished accidentally. I clicked submit post when I meant to hit my MSn window. I think I caught it in time though...sigh...sleep...must have...)

Anyway, your data access components are the classes that know the names of your stored procedures, and which fields to build your dynamic sql from, or whatever it is you need to do with the database. Point is, thats the layer that has any app-specific logic relating to the objects within the database.

So your architecture will look like this:

Class Class
\ /
Data Access Component
|
Generic Data Access Component
(Data Access Block)
|
SQL Server DB

This article actually explains it alot better than I probably just did, but it'll give you an idea of where MS is going:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

hth

D'Arcy

ps: just FYI, I'm actually implementing their suggested architecture in an application right now, so I'll keep you posted on how its going.

 

[dragonwell]

Hi D'Arcy,

Great! Do keep us posted.

All -
I, like many others, am wading through the myriad of options concerning data layer development. I've used the DAAB a lot, but mostly in very simple ways. For instance, in my first few projects, I just put all the data access code right into my domain classes and gave them methods like, "Save" and "Fill" and static "ListAll" functions, putting my SqlHelper.Execute... calls with the correct SP right in there.

Now though, I am becoming more interested in layering, as you decribe above. So far, I am more partial to the generic "O/R Mapper" frameworks which automatically set up all your DAL stuff based on your database schema, and all you do is write business logic (ie - EntityBroker, Deklarit, LLBLGenPro, Raptier, etc, etc...).

So, are you using Stored procedures or Dynamic SQL???? (not that I wnat to get into that debate right now, just want your respected opinion).





David

 

[jby1]

Hi D'Arcy, thanks very much for that, I am getting a great idea of the way I should go regarding data access. Looks reasonably similar to what I was planning to do, although it is always great to get verification, and maybe a different way of looking at things. Unfortunately, the project has been put on hold for the minute, but if it gets going I will let ya know how the implementation goes!

Thanks again

 

[jfrost10]

hey guys, glad the info was helpful


David: we're using stored procs all the way through. Our application doesn't required the generation of dynamic sql calls very much, if at all, and encapsulating all the sql within sp's is a much cleaner way to organize things (my opinion on it anyway).

D'Arcy

 

[dragonwell]

D'Arcy,

I read that paper too and there is something that I have not quite understood yet.

By your diagram you show the entity classes interacting with the DAC classes, and I assume the next step up would be either a business process or UI layer. It is my understanding that that each layer interacts with the layer immediately above or below it only so, f.e., the UI layer would never use the data access classes, rather it would only work with with the business entity classes.

Good so far. Now -

In that paper, they show something like this:

CustomerDALC dalcCustomer = new CustomerDALC();
CustomerEntity aCustomer = dalcCustomer.GetCustomer(21);

Is that how one would instantiate a Customer entity class in the UI layer? To me, that seems like a violation of the multi-layering principle - the UI layer has to instantiate the DAC class to get an entity class.

So does that mean the only way to truly separate you upper layers from the DAC is to use custom business entities with CRUD behaviors?

Regards,

David

 

[jfrost10]

Hey David,

I see what you mean. My guess is that if they were going to show that code properly layered, they'd have to show you the code in teh business object, then show the code in the DALC object, then switch back over to show how the business object fills itself, etc. So by showing the code in one block, they can better describe the flow.

However, as I read it, something struck me: does the data access layer HAVE to be encapsulated within the business layer? For instance, if an object creates an instance of its DALC object, and calls a function that returns an object of its own type, how would the DALC know what type of object to return unless:

a) it has a reference to the business layer assembly (redundant)

b) its part of the same project, meaning that although technically they are seperate tiers, they aren't physically seperated

or
c) the business layer doesn't encapsulate the data access layer. Instead of the top down model we're used to seeing, maybe it works more like this:

Presentation
/ Business--------Data Access
|
Database

So in that case, your presentation and data access components would both have to reference the business assembly (so they could both create/return business objects). Still not ideal.

You could have the data access and business classes part of hte same assembly, but then you wouldn't have physically different tiers (may not be a problem though?)

Your question poses more questions I think. I'll start poking around and see what I can come up with.

Thanks,

D'Arcy

 

[dragonwell]

Update:

I think I've found a great example in the MS PetShop 3.0. You can download the source

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/petshop3x.asp

After studying it's architecture, I'm finally starting to "get it" - how to pass objects through the layers. The missing link that I wasn't seeing was the use of a "Model" structure. The model class has only the properties, kind of like a struct. They call them Info types, like ItemInfo, OrderInfo, etc. Then they have a DAL class that returns these models via a BusinessLogicLayer class. I always thought that the BLL classes defined the properties. but no! - they just define logic and return instances of models.

I know that's not very clearly explained. I am working on a UML diagram of it that I can probably share if anyone's interested.

HTH



David

 

[jfrost10]

Very interested.

One thing that I will warn about regarding the petshop code:

I was at a .NET user group here in my city a few weeks back, and they were going over Microsoft's patterns and practices. They used the Petshop as an example, and said that it was a great example of ARCHITECTURE patterns, but not necessarily design or implementation (coding).

Not that the code should be ignored, but just a comment about the intent of the example.

D'Arcy

 

[dragonwell]

I can see that. In studying the code it is obvious that they were trying to get it done in as few lines of code as possible. Usually that's a good thing, but if I were just starting out trying to copy the style used there it would be very confusing. For example, in a lot of the pages' code behind classes, they don't even bother coding in the Page_Load event, but instead simply override the OnInit method, which works but goes against the Visual Studio way. Most of the "Designer Generatored Code" regions are stripped out, too. All to beat the Java pet shop in getting the fewest lines of code. Maybe for performance, as well.

I am mainly interested in the data-access architecture, which seems to make sense to me. Now, if I can just figure out how to get my code generator to make that framework for me....

David