Custom Entity Classes...

I have been a proponent of Custom Entity Classes over DataSets for some time; and fully acknowledge that the latter has value in certain situations, specifically prototyping or basic two tiered applications. Where as the former, offers greater flexibility for some extra effort that really pays dividends within an Enterprise solution.

The project that I am currently architecting/managing has implemented this style of Entity; this was a foundational decision and certainly a departure from the way the customer currently chooses DataSets. These have worked out extremely well within our solution and I hope they (Customer) will look at this as an alternative in the future for other future applications.

The real benefit I see is that by utilising OO concepts we can realise the benefits of encapsulation and inheritance with our Entities, and we have a clean decoupling from the database (there is in fact no reference to the DB within these whatsoever – data management classes were created for this that lived in an appropriate logical data layer tied directly to the DAL). For a number of our Entities, code generation was used which sped up the creation and also improved the consistency of the code. Typed collections were created that made the experience of using these Entities very natural. Then of course, other Entity specific methods can and were added to these Entities/Collections that offer there own value-add function.

So when I discovered this old article last night I was very pleased to see this very approach promoted. This is an excellent article that articulates the benefits in an easy to read manner, with clear examples, and is an added resource I can now use to help convince future Customers of the benefits of Entities.

My experiences with VB.NET...

For the past four months I been involved in a project where we exclusively developed in VB.NET. This is the most time I have ever spent in this language, and in the end, I would have to say my overall experience was decidedly average.

To me C# just seems more natural, it is somewhat simpler and certainly a lot less verbose. There are some really annoying things with VB.NET, the following being my highlights (main peeves):

• And vs AndAlso and Or vs OrElse – why would you ever want the former, apart from bitwise, yet that is not the default?
• DirectCast(value, type) – versus just casting (type)value; simpler, more obvious.
• Dim – how annoying; it is not even consistent as it is not required for class declarations.
• Public readonly property Name as Type – that’s a mouthful, surely the compiler could determine by looking at whether both a get and set have been defined.
• End – ending everything, bring on the {}.
• Auto formatting – sometimes I want my code to look one way, but “no” the IDE comes along and makes it look another
• Visual basic .NET compiler system error &hc0000005& after a VSS Get Latest - nearly every friggin day! Close VS.NET, cross your fingers, restart and hope for the best – works again first time about 50% of the time.
• VB.NET 1.1 XML comments – why was this missing – hello? Thank you VBCommenter from GotDotNet.
• Nothing vs Null – couldn’t we keep it the same between the languages; so if a parameter is nothing an ArgumentNullException is thrown – huh?

I am sure there are more, but that is all I could come up with for now.

New DbException in .NET 2.0...

There was some talk at work the other day about using Enterprise Library, specifically the Data Access stuff that enabled database agnostic code. There is an issue with this in .NET 1.0 and 1.1 in that not all of the database .NET Types support this capability. Here is an excerpt of my response:

My point was more targeted at the SqlException versus the OracleException type, more specifically where you want to use the likes of the database error code to perform some sort of conditional business logic. The SqlCommand and SqlDataReader et al, implement the likes of IDbCommand and IDataReader so these can be cast back and generic database agnostic code created – great. The likes of SqlException and OracleException inherit from Exception so you are sort of stuffed from that perspective, there is no consistent means to access this database information other that sticking to the known type – not so great.

There is however a happy ending to this story, this has been cleaned up in .NET 2.0. The SqlException and OracleException now both inherit from DbException so this will be possible in the future.