DAAB Wrapper
-
Hi I hope this is the right forum for ths, if not, please direct me to the right one. I looked at DAAB Ent LIb 2.0 January 2006 release. But I did not want to sprinkle the DAAB DLLs all over my different applications. Also, I wanted to de couple my dependency on DAAB such that when a newer version comes and there are breaking changes, I can make those changes only in the wrapper and not in all my projects. Hence I wanted to create a wrapper on top of it. I created a wrapper allright, my idea was that I would return data readers, datasets and adapters from the wrapper. I would then use this wrapper in my app logic layer to get/set data. However, as the reader requires an active connection, I could not pass it through layers. Same for Command objects. I could, however, pass the data table from the populated dataset. Then I exposed a GetConnection method from the wrapper and returned the conn object. I would then use it in App Logic layer to create a datareader etc. However, this approach seems like a hack rather than an elegant solution. Any ideas about how I can go about this? Shreekar
-
Hi I hope this is the right forum for ths, if not, please direct me to the right one. I looked at DAAB Ent LIb 2.0 January 2006 release. But I did not want to sprinkle the DAAB DLLs all over my different applications. Also, I wanted to de couple my dependency on DAAB such that when a newer version comes and there are breaking changes, I can make those changes only in the wrapper and not in all my projects. Hence I wanted to create a wrapper on top of it. I created a wrapper allright, my idea was that I would return data readers, datasets and adapters from the wrapper. I would then use this wrapper in my app logic layer to get/set data. However, as the reader requires an active connection, I could not pass it through layers. Same for Command objects. I could, however, pass the data table from the populated dataset. Then I exposed a GetConnection method from the wrapper and returned the conn object. I would then use it in App Logic layer to create a datareader etc. However, this approach seems like a hack rather than an elegant solution. Any ideas about how I can go about this? Shreekar
shreekar wrote:
I would then use it in App Logic layer to create a datareader etc. However, this approach seems like a hack rather than an elegant solution. Any ideas about how I can go about this?
Data Readers, Connections and so on should stay in the DAL (Data Abstraction Layer - i.e. your wrapper). If you must, create data tables and data sets to pass data out of the DAL. It isn't something I'd do, but it is the easiest thing to do.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
-
shreekar wrote:
I would then use it in App Logic layer to create a datareader etc. However, this approach seems like a hack rather than an elegant solution. Any ideas about how I can go about this?
Data Readers, Connections and so on should stay in the DAL (Data Abstraction Layer - i.e. your wrapper). If you must, create data tables and data sets to pass data out of the DAL. It isn't something I'd do, but it is the easiest thing to do.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
Thanks a lot for your comments. I think I will settle with the datatable solution for now. On a side note, I have read somewhere that the TableAdapter can be used as a replacement for DAAB. Currently, I am using TableAdapters in some forms of the application and after I resolved the connection string issue, it seems to work well. But I am not fully convinced about how well it will handle header-detail or multiple table relationships. The way I see it, using the Table Adapters, I get strongly typed datasets which I will miss in DAAB, but in DAAB, I can design the App Logic Layer and sort of keep it separate from the DAL. Before going the full distance with the DAAB/Table Adapters, I would like to know the pros and cons between using DAAB and Table Adapters. Any thoughts on this?
Shreekar http://shreekarishere.blogspot.com
-
Thanks a lot for your comments. I think I will settle with the datatable solution for now. On a side note, I have read somewhere that the TableAdapter can be used as a replacement for DAAB. Currently, I am using TableAdapters in some forms of the application and after I resolved the connection string issue, it seems to work well. But I am not fully convinced about how well it will handle header-detail or multiple table relationships. The way I see it, using the Table Adapters, I get strongly typed datasets which I will miss in DAAB, but in DAAB, I can design the App Logic Layer and sort of keep it separate from the DAL. Before going the full distance with the DAAB/Table Adapters, I would like to know the pros and cons between using DAAB and Table Adapters. Any thoughts on this?
Shreekar http://shreekarishere.blogspot.com
shreekar wrote:
TableAdapter can be used as a replacement for DAAB
Do you mean DataAdapter?
shreekar wrote:
Any thoughts on this?
I don't use DataAdapters at all. I find they don't give me the control that I want. They produce overly large and cumbersome DataSets with lots of functionality that I don't need. I use my own solution that dumps data in to Data Transfer Objects [DTOs] (basically a very simple class that contains nothing but fields and properties that relate directly to the columns being returned from the database). It is probably too much to explain in a forum post but I got the idea from the way DotNetNuke deals with the database (Search on
DotNetNuke Data Providerfor articles on how their implementation works). Each DTO is very lightweight, typesafe and can work with the DAAB.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
-
shreekar wrote:
TableAdapter can be used as a replacement for DAAB
Do you mean DataAdapter?
shreekar wrote:
Any thoughts on this?
I don't use DataAdapters at all. I find they don't give me the control that I want. They produce overly large and cumbersome DataSets with lots of functionality that I don't need. I use my own solution that dumps data in to Data Transfer Objects [DTOs] (basically a very simple class that contains nothing but fields and properties that relate directly to the columns being returned from the database). It is probably too much to explain in a forum post but I got the idea from the way DotNetNuke deals with the database (Search on
DotNetNuke Data Providerfor articles on how their implementation works). Each DTO is very lightweight, typesafe and can work with the DAAB.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
Well, I did mean TableAdapters - the new thing introduced with VS 2005 (not a part of .Net 2.0) The mapping of fields and columns with the properties is the most natural mapping IMHO and the App Logic layer would have that ultimately in one form or another. My question is - what is the better approach between such mapping and TableAdapters. Shreekar