It's been a theme for me over the past couple of weeks where people have mentioned that they can't afford the time to do modeling. If you've done a lot of UML modeling, you know what I'm talking about. But it doesn't have to be that way. Now just to ward of the UML flames, even when UML modeling seems like a waste of time, it may actual pay for itself if you uncover a requirement or a design flaw that you wouldn't have otherwise. Certainly catching this kind of thing early than later pays for itself. But that's not what I'm talking about.
In my days as an ERwin/ERX user, doing data modeling was done in this tool not only because it was good to visualize something quickly before committing to code. Using ERwin/ERX was just plain faster than cutting DDL code manually - or heck, even using the Database diagramming in SQL Server. One simple feature was foreign key migration - you drew a relationship from parent to child and bam - it copied down the pk from the parent table and set it up as a fk on the child table.
For the VSTS class designer to be successful (or any of the designers for that matter) MS needs to make using them just plain faster than stubbing out the code manually. Visual Studio has a great editor so they have their work cut out for them. It gets even better with things like code snippets. Why not enable some of the code snippets in the class designer? I can still create a single field wrapped up by a public property faster in the code editor using a snippet (in C# “prop“) than using the class designer - but I don't see why they couldn't add support for that in the class designer too.
A feature I stumbled upon last week was the ability to override a member. Simply right click on the descended class, and select “Override Member“ and you'll see a list of members from the ancestor that are overridable. Select the member to override and bam - you have the code stub. This reminds me a bit of the Inherited Class Skeleton Generator. This represents the kinds of productivity features that can make models/designers more usable, even if just for productivity sake.
There are obviously some types of edits that are better performed in the code editor, such as actually editing code fragments. Other types of edits can be performed more appropriately in the model such as stubbing out the api/members of a class, overriding members, etc. Let's not forget the other types of edits which are much better done in a WYSIWYG designer such as the windows or web forms designer.
One thing I'd like to see come in the Class Designer is a flattened out view of a class that collapses all inherited members into one layer. I'll call this the consumer or intellisense view of a class. It's helpful for viewing the entire interface to a class so I can see how the whole thing makes sense to a user. I would propose a greyed out notation or perhaps a lock icon or something similar to the online help view of a class.
You may have noticed that the refactoring menu's that you see in the code editor are also available in the Class Designer. Furthermore, you can also copy & paste things from one class to another. So if you copy a property from one class to another, not only do you get the property added to the class, but also all the code in your getter's and setters. Ok so this is a nice touch that can help with a refactoring effort that requires moving stuff around - but don't consider this code reuse :)
Yes, it's the longest title of all VS Live Orlando presentations! It's a big topic and it deserves a big name.
I'm heading out Monday night to hurricane country to deliver this talk on Tuesday morning. I like this topic because when you get into it, it's like an onion. It doesn't look like something terribly sophisticated but as you get into you find there are more and more layers to peel back.
Ramkumar Kothandaraman has a good article just released on MSDN discussing SOA Challenges: Entity Aggregation. Aggregation is a much better name than “composable entities“ since it's definition implies that property sets of an entity grow as more child entities are merged into it. This also implies that you need a mapping layer and conflict resolution to resolve duplicate property names or just rename them for that matter.
This is becoming an important technique for passing xml documents up the stack of web services, each one adding their own value to the entity - or aggregating in a master/slave hierarchy topology. Either way, one of the subtle things about entity aggregation is that you can also think of it as a lightweight form of multiple inheritance for the properties of your domain objects. Is that useful or am I just bent?
Scott Hanselman does a nice 30 second intro into layered design. If any of this is new to you, run quickly to read this.
Scott does a quick bash at Datasets (although doesn't say why) and in my new role as DataSet boy I have to disagree with him and evangelize how simple datasets can make a lot of the code written by the typical programmer: CRUD stuff for example. He even mentions “Adapter“ in describing a data access layer - come on, use the DataAdapter - don't be afraid. In general, if anybody tells you to never do something, you need to question that a bit and dig into the reasons why a technology exists. Of course things may just end up being rude and the answer is indeed never - but always try and get the why.
We've been running a developer contest at the end of some of our training courses (the big 3 week immersion ones). The competition has developers build a solution build on a services oriented architecture which includes smart client, web services, enterprise services/com+ and of course data access. It's only a 1 day event, but the teams are built up of 5-6 people each. Inevitably, if one team decides to use datasets/dataadapters and the other team doesn't, the team that choose the dataset wins. This competition isn't judged or skewed for datasets by any means. But inevitably this is the thing that gives the other team more time to work on the interesting pieces of the application (like business logic: features and functions).
I over heard Harry Pierson tell a customer last week that they shouldn't use datasets in a web service because they aren't compatible with non .NET platforms. This isn't true. A dataset is just XML when you return it out of a dataset. And you probably more control over the format that is generated via the XSD than most people realize. If you want a child table nested, no problem. You want attributes instead of elements, no problem. You want some columns elements and others attributes, no problem. You want/don't want embedded schema, no problem. You don't want the diffgram, no problem. Somebody in the J2EE world has actually gone to the extent of creating a similar type of base object in Java that can deserialize the dataset in most of it's glory. (Link to come - can't find it right now).
In February I posted a “Benefits of Datasets vs. Custom Entities“ which has generated some excellent feedback. It's still in my plans to write the opposite article - when Customer Entities are better than Datasets but I'm still looking for the best template or example entity. Everyone somebody has sent me to date is somewhat lacking. To be fair, I end up always comparing them to a dataset. The things typically missing out of a custom entity are the ability to deal with Null values and the ability to track original values for the purposes of optimistic concurrency. The answer to the question of “When to use a Custom Entity over a Dataset?“ is of course when you don't need all the stuff provided for you by a dataset. So is that typically when you don't care about Null Values or Optimistic Concurrency? Perhaps. But I know there is more to it than that.
I will say there is some crummy binary serialization in the dataset (it's really XML). This is really a problem if you are doing some custom serialization or need to do some .NET remoting. But you can change the way they are serialized (and indeed it's changed in Whidbey). There are some good examples here, here, here, here, here and here.
I'm working on an article making the cases for the custom entity, but in the meantime, datasets represent a good design pattern for entities that is easy and quick to implement by the average developer - and scalable too.
Sun also fails to address the need for the occassionally connected/offline access application.
This is a new smart client reference application from Microsoft. Actually it was created by Vertigo for Microsoft - where Susan Warren now works (former Queen of ASP.NET). This is not a rewrite of TaskVision which is a common question. It was built to show off some advanced topics for Smart Client apps in conjunction with the recent DevDays events that have been going on in the U.S. but unfortunately haven't made it up to Canada due to some overloaded efforts going into VS Live.
You can download this from Microsoft although it's not the easiest thing to find.
Some of the interesting highlights:
- focus on security....some wrapped up DPAPI classes.
- Application Deployment and Updating
This app wasn't built with the recently released offline application block since the timing wasn't right - but nevertheless, a good fresh reference app worth looking at.
I'm doing this MSDN webcast in a few weeks
10/05/2004 1:00 PM - 10/05/2004 2:00 PM (EasternTime)
In this session we'll cover the world of logging and instrumenting your application. We'll discuss the various .NET framework components as well as higher level services as provided by the Exception Management Application Block, the Enterprise Instrumentation Framework and the Logging BLock. We'll discuss the various issues with persisting information in file logs, the event log, and WMI Performance Counters. We will also compare other alternative technologies such as log4net. We'll also discuss best practices for loging and instrumenting your application and provide some considerations for when and where it makes good sense to instrument your application from experiences in the field.
Update: The slides, samples and livemeeting recording links can all be found here.
So you want to build your own entity objects? Maybe you are even purchasing or authoring a code-gen tool to do it for you. I like to use Datasets when possible and people ask why I like them so much. To be fair, I'll write a list of reasons to not use datasets and create your own entities - but for now, this post is all about the pros of datasets. I've been on a two week sales pitch for DataSets with a client so let me summarize.
- They are very bindable.
This is less of an issue for Web forms which don't support 2 way databinding. But for Win forms, datasets are a no brainer. Before you go and say that custom classes are just as bindable and could be, go try an example of implementing IListSource, IList, IBindingList and IEditableObject. Yes you can make your own custom class just as bindable if you want to work at it.
- Easy persistence.
This is a huge one. Firstly, the DataAdapter is almost as important as the DataSet itself. You have full control over the Select, Insert, Update and Delete sql and can use procs if you like. There are flavours for each database. There is a mappings collection that can isolate you from changes in names in your database. But that's not all that is required for persistence. What about optimistic concurrency? The DataSet takes care of remembering the original values of columns so you can use that information in your where clause to look for the record in the same state as when you retrieved it. But wait, there's more. Keeping track of the Row State so you know whether you have to issue deletes, inserts, or updates against that data. These are all things that you'd likely have to do in your own custom class.
- They are sortable.
The DataView makes sorting DataTables very easy.
- They are filterable.
DataView to the rescue here as well. In addition to filtering on column value conditions - you can also filter on row states.
- Strongly Typed Datasets defined by XSD's.
Your own custom classes would probably be strongly typed too...but would they be code generated out of an XSD file? I've seen some strongly typed collection generators that use an XML file but that's not really the right type of document to define schema with.
- Excellent XML integration.
DataSets provide built in XML Serialization with the ReadXml and WriteXml methods. Not surprising, the XML conforms to the schema defined by the XSD file (if we are talking about a strongly typed dataset). You can also stipulate whether columns should be attributes or elements and whether related tables should be nested or not. This all becomes really nice when you start integrating with 3rd party (or 1st party) tools such as BizTalk or InfoPath. And finally, you can of course return a DataSet from a Web Service and the data is serialized with XML automatically.
- Computed Columns
You can add your own columns to a DataTable that are computed based on other values. This can even be a lookup on another DataTable or an aggregate of a child table.
Speaking of child tables, yes, you can have complex DataSets with multiple tables in a master detail hierarchy. This is pretty helpful in a number of ways. Both programmatically and visually through binding, you can navigate the relationship from a single record in master table to a collection of child rows related to that parent. You can also enforce the the referential integrity between the two without having to run to the database. You can also insert rows into the child based on the context of the parent record so that the primary key is migrated down into the foreign key columns of the child automatically.
- Data Validation
DataSets help with this although it's not typically thought of as an important feature. It is though. Simple validations can be done by the DataSet itself. Some simple checks include: Data Type, Not Null, Max Length, Referential Integrity, Uniqueness. The DataSet also provides an event model for column changing and row changing (adding & deleting) so you can trap these events and prevent data from getting into the DataSet programmatically. Finally with the SetRowError and SetColumnError you can mark elements in the DataSet with an error condition that is can be queried or shown through binding with the ErrorProvider. You can do this to your own custom entities with implementation of the IDataErrorInfo interface.
- AutoIncrementing values
Useful for columns mapped to identity columns or otherwise sequential values.
This is not an exhaustive list but I'm already exhausted. In a future post, I'll make a case for custom entities and not DataSets, but I can tell you right now that it will be a smaller list.
For those familiar with my past life, you know that I'm a supporter of model-driven development - as long as it helps me develop faster, and doesn't constrain me....throughout the entire SDLC.
A couple of years ago, I stumbled on to DENIM and was intrigued, but didn't really take it up. I've been thinking about getting a tablet PC but have really been waiting for the killer app. I thought it might have been One Note, but I'm not too sure on that yet. I used One Note through the beta and lost all of my data on one occasion and have been afraid of it ever since. I have a pretty low acceptance factor (LAF) of applications that hide the location of their data. Maybe DENIM is the killer app I'm looking for.
Do yourself a favour and watch the video. DENIM seems complicated enough that my mom won't be able to do anything meaningful with it. But I could easily see myself getting my mother to watch me draw a prototype application without being bored to tears.