Rants Tagged with “DataSets”
1 2 > >> (Total Pages: 2/Total Results: 17)
I am working on a project where I have separated the Typed DataSets into a separate Assembly. I nievely made the Typed DataSets use a named Connection String in this assembly. So when I attached to the Database when creating my DataSets, I saw that it was using a Connection String called "MyConnection".
In this assembly, the designer created an app.config and a Settings.setting object. All sounded good. So in my ASP.NET 2.0 project, I setup the connection string in the web.config and called it "MyConnection". This all worked until I deployed it to a server, when all hell broke loose. After deployment, my code that did *not* use Typed DataSets (mostly DataSources) worked fine with my new "MyConnection" connection string...but...
Everywhere I used the Typed DataSets it was failing to connect to the database. When I looked at it it seems that the Typed DataSets were using the connection string I used on my dev box...but no app.config to be seen. How was it getting that bad connection string? Well it seems that the connection string information is being embedded as the "default" connection string to use if it can't find the connection string in the configuration. Ok, this is bad...I'd hate for my assembly to actually have stuff like my password embedded in it, but I doubt that happens. I was using integrated security so I haven't tested the password embedding yet.
But what is strange is the connection string was in the web.config. What gives? Well the Typed DataSet satellite assembly named my connection string with namespace and setting prefixes. "MyConnection" became "MyApp.Properties.Settings.MyConnection" because the serialization of the name includes all of that. Yeech...
For now I added that as a connection string to my web.config and got over my initial issue, but I am still digging to find a better solution. I'll let you know what I find.
My article on upgrading tips for your Typed DataSets is up on DevSource. Take a look!
In Visual Studio 2005, when you create a Typed DataSet, it automatically creates TableAdapters for you. These are interesting objects that use a DataAdapter internally to make a more cohesive data access layer. It will certainly help the RAD developers get started. I am not so sure about how they will work long-term though.
One of the more interesting things that these new Typed DataSets do is store a link to connection information in the Typed DataSet. These seems to be used for the TableAdapters to do their open's with. Problem seems to be that if you migrate a Typed DataSet from 1.1, there is no way to insert this connection information. Even if you do, the designer in Beta 2 doesn't allow you to attach TableAdapters to your existing Typed DataSet. This means that if you want to use TableAdapters you will need to re-do your Typed DataSets entirely.
I just finished an article talking about about some of these migration issues. I'll post a link when it gets published.
Not sure how I missed this before. I was very impressed by this discussion of the issues around Typed DataSets. Yeah, sure he agrees with most of my opinions...but I like hearing that as well as dissenting opinions.
In previous builds, the DataSet had a property on them that said whether they should clear the DataSet whenever it is Filled by a DataAdapter. It seems to be missing in the latest builds. I actually prefer this because the nature of DataSets (and often overlooked) is that successive DataAdapter.Fill's will allow a DataSet to grow incrementally. New rows will be added, and existing rows will be updated (unless it is dirty, then you would get an exception).
Maybe my ranting to Steve Lasker paid off in a small way.
The original LadyBug on this is here if you have an opinion and want to vote to have it changed. I've reopened it to figure out what they've done with it.
UPDATE: Steve Lasker correctly pointed out that it is on the TableAdapter (d'oh), but not in the designer for some reason. I am going to update the LadyBug to complain about the designer issue.
I haven't had time to look at this new round of discussions about where DataSets fit into the data world. I am still reformulating my ideas around DataSets after meeting with Microsoft and being told that they did not want to encourage use of DataSets in place of business objects.
I have also been using CSLA.NET at a client and it has some good ideas about entity mapping in general, though it has a number of well documented downsides as well. As Rocky would probably tell you, CSLA has it's place in some architectures but was not meant to fit into all solutions.
My plan is to unveil something new that attempts to address the shortcomings of all the camps (ORM, DataSet, Custom Business Entities), but I am not ready to present it yet. I think we need a good solution for Whidbey and beyond and I don't see that coming out of Redmond (don't get me started on ObjectSpaces ;).
I've spent most of the last week in Redmond seeing some new stuff and meeting up with old friends. While I was here I scheduled some time to sit down with Steve Lasker of the Visual Basic/Visual Studio Team. His team in in charge of the Typed DataSet in Whidbey.
I met with him to discuss the inheritability of Typed DataSets for business logic. If you've been reading much of what I have written in the last three years, you probably know how long I've advocated the use of Typed DataSets as a replacement for Business Objects. Alas, I've finally been convinced by Steve that they never intended Typed DataSets to be inherited.
In our discussion, he suggested using Typed DataSets and registering for events to do simple business logic is where they envisioned to be the limit of that use. They seem to be convinced that the DataSet can be too heavy for certain situations. They've spent a lot of time in the Whidbey bits to make object binding work much better than in the 1.x Framework.
It still seems to me that the inheritant strength of tool-driven data access, built-in storage of current/original data in the DataRow/Table, the implicit 'dirty' flags in DataSets, the DiffGram story in Whidbey and the xsd/Web Services/DataSet crossroads means there is still a strong DataSet story.
The problem as I see it is still that building deep object models is a lot of work. Maintaining these object models is a lot of work. How can we streamline this work? I've always liked the Typed DataSet model because it did not require an Object->Relational mapping. It allows you to model the relational model in memory, but see the relationship as a heirarchy if needed.
I am still not convinced of the simplistic DataSet view I hear from Steve Lasker. I suspect it will take a few weeks for me to really come to a convincing conclusion so what this space for my processing of where I think data access should be in the Whidbey space.
I seem to be getting a lot of questions and reviewing a lot of code that isn't use TableMappings and I wonder why. For example I see this occassionally:
DataSet ds = new DataSet();
SqlDataAdapter da = new SqlDataAdapter();
// Setup Adapter here ds.Fill(ds);
ds.Tables["Table"].TableName = "Customers";
//etc.
The problem here is that you don't even need TableMappings, you could call the fill like so:
ds.Fill(ds, "Customers");
The problem really presents itself when you're returning multiple resultsets because the fill won't take multiple names. The solution is TableMappings:
DataSet ds = new DataSet();
SqlDataAdapter da = new SqlDataAdapter();
// Setup Adapter here
// Setup a mapping for each resultset
da.TableMappings("Table", "Customers");
da.TableMappings("Table1", "Orders");
da.TableMappings("Table2", "Order Details");
da.TableMappings("Table3", "Products");
ds.Fill(ds);
Lastly, this is especially important because if you use Typed DataSets you need to fill the Tables that already exist in the Typed DataSet.
HTH
Check out this excellent post on logical vs. physical data tiers.
I've been spending some time lately reviewing how companies are doing data access in .NET. When I look at how most of them have crufted up solutions, I am amazed. The model that Microsoft supports seems so obvious to me, but I am neck deep in it. I'd like to hear from my readers their specific experience with creating data access in .NET; with an eye to why or why not use COM+ for transactions; Typed DataSet or DataReaders; Business Objects or Messages. I am trying to understand where the community is.
Thanks in advance...
