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 ;).
Check out the first part (of 2) where I discuss the basics of writing managed code inside of
SQL Server 2005.
Forget everything I told you. It's all changed in the April CTP. I hope to re-give this talk soon in the Atlanta area with the new bits.
I am mostly blogging about this so I don't lose the link again, but this is a *great* app that hooks into the Task Manager to do a couple of things:
- Grey's out processes that are Microsoft processes/services so you can see the important ones (see pic):
- Adds an Extension meny that allows you to look for processes that have specific files or modules (great for finding locked files); as well as other tasks (see pic):
Aren't you supposed to get your MCSD before your MVP? Well, I finally finished all the tests for the MCSD.NET and I am happy to have that behind me.
I was listening to Jim Gray today about about lots of interesting ideas (listen to the entire two parts for some fun). But in the second part of the discussion, he talked about another coming of the Client-Server vs. 3-Tier war. He seems to really like
SQL Server exposing WebServices directly. He understands the issues very well. After he mentioned WebServices in
SQL Server he directly brings up the DMZ issue with putting
SQL Server out of the web. I think he's right here. C/S is easier, 3 tier is usually easier to scale. As he says, "They're both right."
Later in the conversation, he brings up the difference between WebServices story from Indigo and his view (RPC vs. Document) and his discussions with Don Box about them. It's nice to see that inside MS the right people are talking about both sides of the argument. I still contend that WebServices are about interop, not IPC. That might leave me in the middle of Don and Jim.
Anyone interested in the future of SQL, WebServices and how the TerraServer was built, take a gander at these talks.
This is a couple of months old, but still worth looking at.
Sure, I am the editor for ONDotnet.com, but I really like this interview. The emphasis is trying to explain to the Linux developer why Mono/CLR development is the way to go. I am in!
I spent most of the evening pondering a problem that I heard about from
Jesse Liberty (author of a number of O'Reilly .NET books). Admittedly, I haven't spent as much time with
ASP.NET 2.0 as I would have liked, so I got down to writing a website with the SqlDataProvider object. Wow, it hides everything. While this will get the small site up and running very fast, I am afraid it will point people are creating lots of single resultset queries. Back to ADO land.
Ok, but what if you want to use a
DataSet to hold hierarchical data? Well, the
DataSet and DataAdapters not only are not on the Data Palette (like they should be), but for some reason you can't even add them manually. The only way I could get this to work was to create a
DataSet in a separate project (yes, a separate project) and reference that project from the Web Project. Even so, I was still left with creating a Typed
DataSet and a Component for the Adapters like I do in 1.x. If they are going to add the idea of a TableAdapter to the Typed
DataSet (good idea guys), we also need allow DataAdapters to be added to the Typed
DataSet. Why? Because retrieving your data one table at a time is a bad practice. Again, DataAdapters do a good job of retrieving batch resultsets and mapping them to an entire Typed
DataSet object.
I know there was a lot of blowback about the traditional single resultset bunch who were used to working a certain way. Allow the case where a single resultset is needed is a great step forward, but don't erase the larger case to meet that demand. Please...
Maybe the strategy continues to be, "Don't use Typed DataSets...go back and create Data Libraries of Objects". Please don't give us tools and then take them away when we're finally getting good at them.
Hmph!
