Arguments - n-Tier Architecture - DAL

[Anders S. Willumsen]

Can someone give me a few arguments for implementing a DAL Layer? Why
develop a BLL and a DAL in the same layer? Is it easier to scale out when
you have a DAL?

I can see a few benifits

1) Easy development - one group can develop and optimize dataaccess without
recompling BLL
2) Its possible to switch database or have a app that can use multiple
databases

But in a "small" project where database is fixed to sql server - whats the
benefits?

Can anyone help?

Thanks

 

[Guest]

The DAL, if correctly designed, becomes a core framework element. This means
you can use the same DAL across multiple projects. If this is the DAL you
envision, the reason for having separate BLL and DAL is obvious.

From another view: If you are working multiple small projects, once you
solve the DAL problem for one, you can dupe it for others (or reuse, if you
are talking the same client).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Alvin Bruney - ASP.NET MVP]

on the other hand, some small projects tend to lend themselves well to going
from front end straight into the back end. It depends on your defintion of
small and how these applications will evolve in the longterm. If there is no
longterm associated with them, what's the point of a DAL overkill?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006

 

[Guest]

I agree with you. If, for example, you are setting up a employee satisfaction
site, that only needs a few questions answered, configuring for a DAL is
probably overkill. It is not wise to pull out a bazooka to kill a gnat. In
these smaller, or one time use, apps, I would advocate getting them set up as
quickly as possible without the overhead.

If, however, you find yourself writing the same software in numerous apps,
you are better to refactor down to some common, reusable components. This
does not mean that you do not have simpler apps at some time, but rather that
core libraries speed up development in the end (like the BCL in .NET).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

on the other hand, some small projects tend to lend themselves well to going
from front end straight into the back end. It depends on your defintion of
small and how these applications will evolve in the longterm. If there is no
longterm associated with them, what's the point of a DAL overkill?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

The DAL, if correctly designed, becomes a core framework element. This means
you can use the same DAL across multiple projects. If this is the DAL you
envision, the reason for having separate BLL and DAL is obvious.

From another view: If you are working multiple small projects, once you
solve the DAL problem for one, you can dupe it for others (or reuse, if you
are talking the same client).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************