Rants Tagged with “.NET”
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've been digging deep in to ASP.NET 2.0 the last couple weeks and I have been pleasantly surprised by a number of nice changes that probably didn't make the new features lists:
- Markup Designer Errors: When you have a problem in the markup of a page and it can't show itself in the designer view, you get errors to follow up and fix (not the 1.1 version where it just complained about the first one).
- Localization Support: Wow! You can tell VS.NET to build resource based localization and the resource files are strongly typed.
- IIS Support for web.config: IT support for modifying the web.config file in IIS is sweet. The web-based one isn't bad, but the IIS one rocks.
In addition, I was surprised by the intuitive forms authentication controls. I was using the PasswordReminder control and wanted to capture the reminder and change the password to reset the password instead of remind them of their password since we were just storing the hashes. But after digging in deep, I found out that since I setup the personalization to store as hashes, it was resetting the password.
Pretty impressive results against 1.1, Java/Sun and IBM.
Of particular interest is the DataSetDataSource object which is being postponed. Though you can use the ObjectDataSource to bind to a Typed DataSet so it's not that much of a death-knell. Check it out...
With
Microsoft reporting that it will release BT 2006 with VS and
SQL Server 2005, I guess I have some catching up to do. I am a little confused by their discussion of BT 2006 not really being available until 1st Quarter 2006. Anyone know the truth?
DevSource has my new article up continuing the discussion of the CLR integration in
SQL Server 2005. Take a look!
And they're up on MSDN! Wahoo!
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 ;).
After looking over the latest Data Access Block, i'll say it is better. But I still have my gripes:
- They are still calling PrepareCommand with an open connection. Even if you get the parameter out fo the parameter cache, the check with teh Database is still going to happen. I think a code-gen solution (a la Typed DataSets) for Command objects is a good idea (and Whidbey and I both have different ways to handle this).
- There is still no way to update multiple datatables within a single transaction.
- There are still issues with Table/Column Mappings in that they are being obfuscated from teh user therefore they'll never know when they can use them.
It is better in a number of areas though:
- Much better connection management.
- More more generalized away from SQL Server. Complete usage of IDb* interfaces helps, but real database independence is a pipe-dream IMHO.
On the whole though, I'd still recommend not using it and rolling your own DataAccess object with some of these ideas, but not most of them.
I have talked with many people over the last few years about my issues with the the Data Access Block, but it seems I've never enumerated my issues in 'print'. Here they are. If this has been fixed in the EL version the Data Access Block then yippie!
- PrepareCommand is called from many of the helper functions. PrepareCommand causes the connection to be open before the Parameters are adding to the connection. This causes each parameter to be 'checked' with the server causing many unnecessary round-trips.
- Opening connections too early and closing them too late.
- Obfuscates the way the data access works so when there is an issue, the users must dive into levels and levels of overloaded methods to find the private method that is really doing the work.
- Filling DataSets is doing TableMappings but no ColumnMappings. Hiding this detail from developers only delays the learning of this important concept.
- No support for multiple DataTable updates within a single transaction.
