Designing the Data Access Layer

[Abraham Shilon]

Hi guys,

We're facing a design issue regarding how to design our DAL.
As we all know, in its most basic definition, the DAL means the layer
that is responsible for communicating with some data repository (of course I'm not talking about the Repository pattern),
usually a database. Now this is where the catch is.
Some of our business objects would have to get their data from the database, and some would get their data from other sources, i.e web services.
A few of our members on the team suggested that the BO's should be smart enough about knowing whether to call a DAL (that only knows to talk to the database)
or call the required web service. Others suggested that this might not be an optimal solution, suggesting that everything should pass through the DAL, where it would contain let's say adapters, or whatever,
for each data retrieval method.

How would you architect a system with such data access needs?
Is any of the suggested solutions might be good enough for the long run (the 2nd one might take more time to develop)
or do we need to take a totally different approach?

Thanks,
Avi Shilon

[Sergei Gorlovetsky]

Hi,

Look at Application Architecture Guide 2.0  http://www.codeplex.com/AppArchGuide

It will probably solve most of your concerns regarding the heterogeneous DALs.

Cheers,

Serge.

[Abraham Shilon]

Thanks Serge, I'll have a look :)

[Ariel Raunstien]

What data comes from WSs?

Arielr

http://blogs.microsoft.co.il/blogs/ariel/

[Abraham Shilon]

A custom type that is built (using the Builder pattern) according to some business logic is sent to the web service.
The web service does its stuff and returns another custom type, that is then built into a BO/Domain Object.
I can't tell the exact types that are sent and received. I'll have to ask one of the business developers (which will be only tomorrow morning).
But I can say that there are several such web services, each with its own custom types, so it's might get a little nasty.
If we can come up with a clean and elegant solution, that would be great.

Thanks :)

[onemenny]

i suggest using the adpaters approach. the BO's "must" be ignorant
regarding the DAL.
looking at IOC, DI, Repository and the Microsoft EF guys architecture
you can conclude the general direction of things is adapters.

your solution should be tailored using a bounch of the above. as a
good practice i would leave the BO's out of the picture!

On Sep 22, 12:47 am, Abraham Shilon <avi.shi...@gmail.com> wrote:
> A custom type that is built (using the Builder pattern) according to some
> business logic is sent to the web service.
> The web service does its stuff and returns another custom type, that is then
> built into a BO/Domain Object.
> I can't tell the exact types that are sent and received. I'll have to ask
> one of the business developers (which will be only tomorrow morning).
> But I can say that there are several such web services, each with its own
> custom types, so it's might get a little nasty.
> If we can come up with a clean and elegant solution, that would be great.
>
> Thanks :)
>

> On Tue, Sep 22, 2009 at 12:25 AM, Ariel Raunstien <arie...@gmail.com> wrote:
> > What data comes from WSs?
>
> > Arielr
>
> >http://blogs.microsoft.co.il/blogs/ariel/
>