BLL & DAL: How are they different?

[Mark Rae [MVP]]

I don't have to change my DAL for any specific application.

Me neither...

I only change it if there is a TSQL change.

I don't even have to do that...

 

[Mark Rae [MVP]]

How do you manage shifts between database servers or even other storage
mediums (webservices, etc.) with this though?

Factory pattern...

IMO this is contrary to the purpose of abstraction as you are placing Data
Access implementation details inside your BLL.

My BLL interfaces with my DAL, never directly with the RDBMS...

It's great if you only have one place in your BLL where that data is
accessed,

??? My BLL interfaces with my DAL all over the place - everywhere it needs
to, in fact...

but what about cases where you need a different solution to retrieve your
data

Factory pattern...

 

[andrew_stevens]

Hi Mark,

I know this is an old post but some of your posts are confusing me, I wondered if you'd mind answering a few questions.

So, you have a BLL that is tightly coupled to your chosen type of data store i.e. you are using the classes from SqlClient (or the Data.Common classes etc). Your DAL is completely dumb, presumably it contains some sort of generic methods that take a command name/text, parameter collection, etc and return data tables/scalar values as appropriate. Am I correct so far?

You then say you use the factory pattern where you need to access data from different sources. Where exactly does this fit into your design? Given the other persons example, say you had to access a web service to retrieve data for a given application. Where would your "factory" come into play? Between the DAL and BLL? Does that mean in your concrete web service data access class that you have to convert the SqlParameter objects into something usable in a web service context? Or does the factory sit between the UI and BLL, and you duplicate your BLL code but change the parameter collections etc to something else?

Does this make sense?