Suggestions - Creating DAL Using DAAB

  • Thread starter Thread starter Richard Martin
  • Start date Start date
R

Richard Martin

Hello.
I need some suggestions regarding an application that I'm working on. The requirements/design spec. indicate that the application needs a separate data access layer, but I'd also like to use the data access application block. We'll be using SQL Server only as the provider.

So, what's the best way to create this separate layer that uses DAAB? I don't believe we need anything as complex as the factory pattern (since we're only having one data provider). But, simply creating a class that calls the DAAB and then returns the results to the calling app seems a little too basic and not very OO. Am I missing something? Are there any good examples?

Thanks.
 
Unless you can provide some more information I would recomment just having your business layer communicate directly with the DAAB. There are a lot of factors that need to be considered when making a decision like this:

How big is the application?
How much will the application change over time (especially at the schema/stored procedure level)?
How complex is the application?
How much time do you have to develop the application?
+ a lot of other questions.

In general though, having the business layer communicate directly with the DAAB is the way to go. If you're developing what will be a huge enterprise application it may be better to write your own DAL, but I doubt it.

Just my two cents,
--
Sacha Charbonneau-Leblond
Software Developer
Syntapa Technologies Inc.
Hello.
I need some suggestions regarding an application that I'm working on. The requirements/design spec. indicate that the application needs a separate data access layer, but I'd also like to use the data access application block. We'll be using SQL Server only as the provider.

So, what's the best way to create this separate layer that uses DAAB? I don't believe we need anything as complex as the factory pattern (since we're only having one data provider). But, simply creating a class that calls the DAAB and then returns the results to the calling app seems a little too basic and not very OO. Am I missing something? Are there any good examples?

Thanks.
 
In addition to those fine comments,
the MS DAAB can be easily extended to use other Databases.

After I wrote mine for Oracle and SQL Server I compared it to the MS DAAB and was surprised how close they were.
(I admit the DAAB didn't make a whole lot of sense at first or second glance.)
So I built a couple of samples and then finally got going. When I was done, I was able to review the DAAB and tweak mine to account for some minor differences. Now I can go against either Oracle or SQL Server.

The DAAB is a very good DAL.

Your Business Objects should communicate with it directly.
--
Joe Fallon



Unless you can provide some more information I would recomment just having your business layer communicate directly with the DAAB. There are a lot of factors that need to be considered when making a decision like this:

How big is the application?
How much will the application change over time (especially at the schema/stored procedure level)?
How complex is the application?
How much time do you have to develop the application?
+ a lot of other questions.

In general though, having the business layer communicate directly with the DAAB is the way to go. If you're developing what will be a huge enterprise application it may be better to write your own DAL, but I doubt it.

Just my two cents,
--
Sacha Charbonneau-Leblond
Software Developer
Syntapa Technologies Inc.
Hello.
I need some suggestions regarding an application that I'm working on. The requirements/design spec. indicate that the application needs a separate data access layer, but I'd also like to use the data access application block. We'll be using SQL Server only as the provider.

So, what's the best way to create this separate layer that uses DAAB? I don't believe we need anything as complex as the factory pattern (since we're only having one data provider). But, simply creating a class that calls the DAAB and then returns the results to the calling app seems a little too basic and not very OO. Am I missing something? Are there any good examples?

Thanks.
 
Thanks for the great info.; it'll really help. I think the light bulb is beginning to flicker on.

Unless you can provide some more information I would recomment just having your business layer communicate directly with the DAAB. There are a lot of factors that need to be considered when making a decision like this:

How big is the application?
How much will the application change over time (especially at the schema/stored procedure level)?
How complex is the application?
How much time do you have to develop the application?
+ a lot of other questions.

In general though, having the business layer communicate directly with the DAAB is the way to go. If you're developing what will be a huge enterprise application it may be better to write your own DAL, but I doubt it.

Just my two cents,
--
Sacha Charbonneau-Leblond
Software Developer
Syntapa Technologies Inc.
Hello.
I need some suggestions regarding an application that I'm working on. The requirements/design spec. indicate that the application needs a separate data access layer, but I'd also like to use the data access application block. We'll be using SQL Server only as the provider.

So, what's the best way to create this separate layer that uses DAAB? I don't believe we need anything as complex as the factory pattern (since we're only having one data provider). But, simply creating a class that calls the DAAB and then returns the results to the calling app seems a little too basic and not very OO. Am I missing something? Are there any good examples?

Thanks.
 
Thanks for your comments too. I really appreciate it.

In addition to those fine comments,
the MS DAAB can be easily extended to use other Databases.

After I wrote mine for Oracle and SQL Server I compared it to the MS DAAB and was surprised how close they were.
(I admit the DAAB didn't make a whole lot of sense at first or second glance.)
So I built a couple of samples and then finally got going. When I was done, I was able to review the DAAB and tweak mine to account for some minor differences. Now I can go against either Oracle or SQL Server.

The DAAB is a very good DAL.

Your Business Objects should communicate with it directly.
--
Joe Fallon



Unless you can provide some more information I would recomment just having your business layer communicate directly with the DAAB. There are a lot of factors that need to be considered when making a decision like this:

How big is the application?
How much will the application change over time (especially at the schema/stored procedure level)?
How complex is the application?
How much time do you have to develop the application?
+ a lot of other questions.

In general though, having the business layer communicate directly with the DAAB is the way to go. If you're developing what will be a huge enterprise application it may be better to write your own DAL, but I doubt it.

Just my two cents,
--
Sacha Charbonneau-Leblond
Software Developer
Syntapa Technologies Inc.
Hello.
I need some suggestions regarding an application that I'm working on. The requirements/design spec. indicate that the application needs a separate data access layer, but I'd also like to use the data access application block. We'll be using SQL Server only as the provider.

So, what's the best way to create this separate layer that uses DAAB? I don't believe we need anything as complex as the factory pattern (since we're only having one data provider). But, simply creating a class that calls the DAAB and then returns the results to the calling app seems a little too basic and not very OO. Am I missing something? Are there any good examples?

Thanks.
 
Back
Top