I see that this is the second version of this. Has anyone been using it??
What are some of the reasons for or against it??

---

No Animals were harmed in the making of the Application

Hammer12

Hi,

I've been using it in some applications. It's a great way to centralize some of the data access code, and the parameter caching can help app performance by reducing round trips to the db server. The second version cleaned up a bunch of stuff.

Don

---

Don Kiely, MCP, MCSD
In the Last Frontier, Interior Alaska
Please post questions and replies to the forum! And remember to MARK AS ANSWER when someone definitively answers a question or resolves a problem!

I've been using it for tons of my apps. It is a great helper utility in making db calls. I didn't even realise a new version was released recently. And support for typed datasets now. Woot!

This app block is highly recommended!

LH

And, best of all, you can use it with Option Strict On! Woohoo!

---

Don Kiely, MCP, MCSD
In the Last Frontier, Interior Alaska
Please post questions and replies to the forum! And remember to MARK AS ANSWER when someone definitively answers a question or resolves a problem!

I am just curious that if it is so great and an example of MS programming pratices then why wasn't it used in any of the Starter Kits?

Or is it not suited for that type of application?

I am not trying to talk it down I am just curious why it never had much attention before?

---

No Animals were harmed in the making of the Application

Hammer12

afaik, DataAccess Application Blocks are used in MS Starter Kits.
Actually, I have discovered Data Access AB via a link in the source code of TimeTracker kit.
I have been using a few other open source DAL's (even attemped to write my own), but imho this is the best (or one of the best) solution available. (Also a good sample usage of Singleton design pattern)

The DAAB is also relatively new, so it will take time for them to use. The Starter Kits weren't developed by Microsoft but by independent devs, so it seems like they were on their own about whether to use the DAAB. But as the other post says, some use it.

Don

---

Don Kiely, MCP, MCSD
In the Last Frontier, Interior Alaska
Please post questions and replies to the forum! And remember to MARK AS ANSWER when someone definitively answers a question or resolves a problem!

When the first Starter Kits were released (IBuySpy) the data access block wasn't there yet.

I even didn't realize there is a special forum to discuss the DAAB. The following is the knowledge I knew about DAAB:

1. Two versions and their difference:
It is a pretty new stuff, the DAAB version 1.0 release on 4/23/2003, while the version 2.0, dated on 6/27/2003.
Version 2 of the DAABlock requires Visual Studio 2003, it doesn't compatible with or work for the current Visual Studio .NET.

2. Use of DAAB in Starter Kits:
It is used by Time Tracker Starter Kit and Report Starter Kit. Some Starter Kits used it, some not. I guess it is not due to the time that if the DAAB is released, but due to the strategy the Starter Kit used itself. See the release dates for some Starter Kits (from its white paper):

Commerce Starter Kit: October 2002
Portal Starter Kit: November 2002
Report Starter Kit: November 2002
Time Tracker Starter Kit: November 2002

The strategy the different Sarter Kit used:
Time Tracker and Reports Starter Kits used the typical 3 tier strategy, that is the reason they used DAAB.

Commerce, Portal and Store Starter Kits (including IBuySpy Portal and Store) used the 2 tier strategy, i.e. they mix the BBL within either UI or DAL. And they didn't use DAAB. It might be reasonable, because the project is quite small, and don't have much business logic, without a clear 3 tier it even might make development easier.

Community Starter Kit used a totally different strategy for its structure, it build its pages on fly. But, actually, I don't understand why it didn't use DAAB. In its code, they use xxxUtility to handle the database access, they have at least 20 some xxxUtility, a tremendous code repeating. I believe, using DAAB should make its code much simpler and more maintainable than what they have right now.

3. Is it great?
Personally, I view it so great, it could be a universal tool in my or our program to handle the data access activities without any worry by ourselves. Even there were some insufficient considerations in the current code, a team from Microsoft would do the backup. Image, can you do better job than the DAAB team?

The only negative concern for me is its performance. But, I concluded it is not big deal. I would discuss this issue in another thread at Performance Or Me.

---

MCAD.NET (C#)


MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0

By the way, there is a bug in DAAB's sample version 1.0 client testing code, it has been fixed with DAAB version 2.0.

The bug is when the client code uses SqlHelper.ExecuteReader to bring back a DataReader, it doesn't close the DataReader, which leads to a connection leaking. If you are interested, please see 231410, at the bottom.

---

MCAD.NET (C#)


MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0

The only negative concern for me is its performance. But, I concluded it is not big deal. I would discuss this issue in another thread at Performance Or Me.

Sorry, I promise to give a conclusion about this on 7/29, but have not had chance to do it till today. But, the test did show, that there is no performance loss when using DAAB. Good news.

---

MCAD.NET (C#)


MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0

Is it a better programming style than using a DAL generator like LLBL?

---

No Animals were harmed in the making of the Application

Hammer12

Is it a better programming style than using a DAL generator like LLBL?

It's different, that's all. LLBLGen creates stored procedures and generic business objects based on the tables in your db, which use ADO.NET to interact with the stored procedures.

DAAB, on the other hand, is a replacement for the ADO.NET code in the business objects.

So I suppose you could say that what LLBLGen is a superset of DAAB, but that really wouldn't be accurate. Maybe that DAAB is a superset of ADO.NET? Maybe....

Don

---

Don Kiely, MCP, MCSD
In the Last Frontier, Interior Alaska
Please post questions and replies to the forum! And remember to MARK AS ANSWER when someone definitively answers a question or resolves a problem!

I'm just curious how many people actually build the data model before the application? A lot of people claim that tools like LLBL are great, however these are the same people that never take the time to create REAL applications. What do I mean by REAL? Well thought out, documented, designed, engineered, architectured, structured applications...

These tools are still using the old concepts of building an application based on data... and not the purpose of the application.

If you build the application based on its purpose and clearly map out the use cases, extract the components of hte application from the use cases, and design your classes that way... then build a data model that will allow you to persist the data that needs to be saved... you will 1) wind up with a superior architecture/api 2) have a better normalized datamodel that will increase performance 3) feel satisified that you are not just one of the RAD kids on the block...

As developers we have the right to DEMAND timelines to do this... if companies cannot accept the time required to do it the right way, then they can either get it the wrong way and pay for it later on, or do it the old way of RAD and have it fail after so long or cause so many problems later on that it ends up costing them more in the long run...

I know, all they care about is up front costs... well as developers we've become so used to saying yes to anything they demand... it seems we have given up on what we used to believe in... that if we take the time to build applications the right way... we can build others faster because we learned how to solve specific problems and have the proper documentation for the solutions...

I'm not going to sit here and say all this and then be like, I've never done any RAD... because all of us have... its what industry demands... I just would like to see the developer community say, enough is enough... we will no longer create insecure, unstable, unscalable, unmaintainable applications just because you want to save a few pennies...

Phew... needed that... I'd be interested to hear if anyone else agrees with me, and who doesn't and why... 8) I know even if we stood up and said enough is enough, its not likely to change anything since we don't control the money... but we could change that given we start going into jobs and extending our timelines by 50% and give it proper attention each application deserves... I don't know about you but i'm sick of cleaning up other peoples messes ...

I've just read your post my friend and im reading thinking yep and nodding my head to every point you have made.

Its so true whats you so and im currently in the middle as usual of exactly what you mean.

I also spent a long time looking inot the data access block and then at data access methods and have came to the conclsusion that you create your data access around your application and for your application - not some generic data access code that doesnt fit your needs.

Oh and im currently working on a large project which is a big mess due to the lack of any real analysis or decision making at the start.

My previous company spent the time to do things right and this is me back to square one.

Cheers
Gregor Suttie

---

Gregor Suttie
MCSD, MCAD, MCSD.Net
http://www.gregorsuttie.com

I use my custom tool: SqlScope

http://www.lostinet.com/files/sqlscope.rar

---

Lostinet (Li Jian Dai) .NET MVP

http://www.lostinet.com/ for LWTree/DatePicker

http://www.contextboundmodel.net/ for AOP.NET

It seems that LLBLGen only works for VS .NET 2003. After installing VS .NET 2003, I have tried LLBLGen. Now, maybe I can have some input about the issue adweigert raised.

These tools are still using the old concepts of building an application based on data... and not the purpose of the application.

It seems adweigert wanted to talk about these tools of Data Access Layers in general, but he just mentioned the shortcomings from, say, LLBLGen.

If you build the application based on its purpose and clearly map out the use cases, extract the components of hte application from the use cases, and design your classes that way... then build a data model that will allow you to persist the data that needs to be saved... you will 1) wind up with a superior architecture/api 2) have a better normalized datamodel that will increase performance 3) feel satisified that you are not just one of the RAD kids on the block...

This is true for a typical three tier application development, and expecially true for the layer of BLL within which the data access logic is located as part of Buseness Logic. Because for three tier application, the data access logic is mixed with Business logic, it is dependent on the busuness logic and should be optitimitically architectured application by applicatioin.

However, if the data access logic was separated from BLL, i.e., building a four tier application, it might be different. For the experience of myself, at the beginning of my developing a three tier application, I didn't intent to have a separated DAL, I mixed DAL and BLL together. But, when the program grew up, I saw some activities, such as open connection, select/insert/delete/update, and others, frequently and repeatedly occurred. Then I built a separated class called internal tools, which were mostly related to these data access activities, to handle the repeated activities. When I moved to the next project, I found with some minor modifications, I could just used the previously developed class of 'internal tools' to handle the data access activities in the new project. After several projects, I had already built my own DAL repeatedly used for a general purpose.

When I saw MS DAAB the first time, I found this DAL was, almost, just a super and better set of the DAL I developed before and a optimitic one, although it doesn't really cover what functionalities I have in my 'Internal tools'. Then, I use MS DAAB anywhere I used the internal tools of myself. This DAL is really application independent, neither dependent on database or buneness logic, and it could be used repeatedly.

BLLGen is a different kind of DAL of MS DAAB. It is database dependent, and then also could be viewed as business logic dependent. In the free offered version, one could only build the layer based on a specific table of a database. I expect that in the paid version, it could work for complex SQL logic. Then, in a four tier application, after you finished the business layer when you should know the all SQL logic to database, you could build DAL layer and database layer (Stored Procedures) together with BLLGen. I think that is a possible choice, although I have not used it in my project.

---

MCAD.NET (C#)


MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0

I wrote these comments in another thread but they bear repeating. (see below) In a nutshell I wrote a code generator that utilizes Microsoft Data Access Application Building Block. Frankly every table requires CRUD logic so why spend tedious hours writing this code when it can be generated in a few seconds. Of course the code generator doesn't preclude a developer from properly engineering an application by utilizing Use Cases and fully normalizing the database. The primary motivation for any CRUD generator, in my opinion, is to codify best practices and generate high performance, error free code that speeds up he development process considerably. Nothing wrong with that :)



My comments from another thread...

Hi All

I have recently written a CRUD Generator that uses Microsoft.ApplicationBlocks.Data so if anyone is interested please let me know. The generated Classes and Stored procedures support ACID principles. The CRUD generator essentially encapsulates all my working knowledge into one neat little package to save myself considerable development time. (WinForms app)
I basically followed the KISS and 80/20 rules when writing this little app so it is by no means perfect. In my case the tool creates 70-90 percent of the data access code I will ever need for a given database in a matter of seconds.

The CRUD generator addresses the following issues:
Transactions - updates, inserts and delete methods are overloaded to support optional passing of transaction objects. In that way you could manually create a composite class that utilizes two or more CRUD generated classes and pass a transaction to all the participating objects. Either all the changes commit or everything is rolled back.

Optimistic concurrency - All a DBA needs to do is add CreatedDate (datetime) column to table and CRUD generator will create all the necessary logic to check for optimistic concurrency violation. Only stipulation is that the developer passes original Datetime value back to procedure so valid comparison can be made.

I leave cascading deletes and restricted deletes up to SQL server as it should be. In all delete stored procs the CRUD generator simply traps error 547 (foreign key violation) if user attempts to delete primary key that is referenced in another table. I then throw a friendly error message using RAISEERROR.

CRUD Generator Limitations: <-- I would not characterize these issues as limiatations but others may. ie C# developer
- Every table must use a single column to represent tables primary key. The column must utilize IDENTITY attribute and appear as first column in table.
- Binary data types are currently not supported.
- Only supports SQL Server
- Only VB code is generated

Some additional features of CRUD generator:
- User can point to new database by simply changing connection string in applications config file
- User can select one or more tables they wish to generate classes or stored procedures for
- User can specify namespace that all classes will utilize
- User can specify which methods and stored procedures are generated (i.e. insert, delete, update and so on)
- User can specify if they want datareaders or datasets returned to client applications.
- All the stored procedures are written to a single file for convenience
- Each table has its own class generated. The naming conventions is table name followed by DB suffix. For example, Employees table would have generated class called EmployeesDB.
- For CRUD generated select procedures the user may optionally define additional columns that are included from related tables
- The CRUD generator will generate select procedures for all foreign keys found in a table. By foreign keys I mean columns with a suffix of ID. ID is simply the convention I use. For example, imagine Employees table had a field called ManagerID. The CRUD generator would generate a stored procedure called EmployeesGetByManagerID that could be used to retrieve all the employees that fall under a given manager.

I took a look at LLBGEN as well and I thought it generated a lot of unnecessary code.


Regards,
Kevin Weir
[email protected]

I saw your repeated comments, at least, three times in different threads. It seemed you didn't follow the 'code-reuse' rule. Is that your coding style, too?

---

MCAD.NET (C#)


MCP on: SQL Server 2k Design&Iimplementation, Web Development (VI 6.0) and VB 5.0

Hi ghan

Not sure I follow.... The generated CRUD classes can be placed in their own assembly and reused in apps including Windows Forms, APS.NET and Web services.