March 2007 - Posts

C# 3 Automatic Properties - Are they any good?

posted Monday, March 26, 2007 4:09 PM by richardSlade
C# 3 Automatic Properties - Are they any good?

Microsoft have gone a long way in the latest versions of .NET languages to make them more terse. They seem to have mainly done a good job in this area. Some language enhancements for the sake of less typing ensures that, in my opinion, the code becomes harder to read, but in the case of automatic properties this is not the case.

Automatic properties simply allow you to type less when defining your simple properties. So, imagine a class that contains the following:

private string mystring;
public string yourstring
{
get { return mystring}
set { mystring = value; }
}

Instead of typing this, you can simply type:

public string yourstring { get; set; }

Nothing is lost when trying to read this property. The C# compiler will automatically create a private variable but this cannot be referenced. If you really need to reference the private variable then you can always go back to longhand but it's a great way to get your properties off the ground without having to write too much code.
Ok - so some may be asking why if we are only going to get and set a property do we not use a public field instead. There are good reasons. Personally I hardly ever use public fields. Public fields are not as easy to bind to as a property and if you want to add validation (for example) then you cannot simply swap to a public property at a later date with ease.

So, automatic properties are a great way to get your properties up and running. Whilst you do have to create a get and a set (no read or write only) they provide another faster way to code that is easy to understand.

Cheers,

Rich
with 0 Comments

Extension Methods mystery

posted Tuesday, March 13, 2007 7:25 PM by richardSlade
Extension Methods mystery

I had the pleasure of attending the MSDN roadshow up in Harrogate today. Very interesting all round I must say but I was particularly impressed with some of the new language enhancements that are soon to arrive. One particular language enhancement that caught my eye was Extension Methods.

For those that have not yet seen this new language enhancement, an extension method basically allows a developer to add a method to a utility or service layer class and then treat it in intellisense as if it were part of the object that they were servicing. Imagine having a sealed car class that you wanted to extend no further with new methods, but added a utility class that would take in a car object and clean it for you. By simply adding the "this" keyword in front of the car parameter it would now appear in intellisense as car.clean(). Great - it's now easy to know all of our service layer methods that are not part of the object.

This was presented by Microsft UK's excellent Daniel Moth. Based on my previous article on Anemic Domain Models I asked Daniel if he thought that this was Microsoft actually supporting an Anemic Domain Model. The answer was no of course. Methods can still be added to the object which is often where they belong. However, Microsoft deliberatly adding this type of support into the language does go some way to showing that moving methods out into a service or utility layer is no bad thing and that they recognise that many developers are creating utility layers instead of shoving everything into the domain objects. Hooray for Extension methods.

Cheers

Rich
with 0 Comments

SQL Search tables

posted Sunday, March 11, 2007 4:59 PM by richardSlade
SQL Search tables

Working on a small project that we have on at the moment, a site is being built. The site uses a SQL database to store basic information. In one of the tables there is (quite commonly) a varchar field in which is held names. All I needed to do was pass my database several names to search on and ensure that it performed in a pretty quick fashion. I could pass it just one name or perhaps several. This wasn't something that we would know until runtime.

Not being a SQL kinda person I was thinking of passing in the items in an XML string, parsing these using OPENXML and using a common "IN" statement or even building up a bit of dynamic SQL using the "OR" statement and then executing that. Until I was told about a handy trick to speed this up, especially as the table grows to thousands of rows.

Many (mostly DBA type people) probably already know what I'm going to say. I've kept the part where I pass in the XML string and parse it using OPENXML, however putting these items into a table variable and then joining my main table to it prooduces lightening fast results. Works like a charm.

Cheers

Rich
with 0 Comments

Anemic Domain Model - and why I like it

posted Wednesday, March 07, 2007 6:37 PM by richardSlade
Anemic Domain Models

Why do I like the anemic domain model? Martin Fowler, who I have much respect for describes the anemic domain model as an anti-pattern. The anemic domain model (from now on referred to as the ADM) is the opposite to the Rich Domain Model (referred to as the RDM).

The RDM is OO purist and mixes the domain logic with the domain objects. So, for a car class, all of the car type methods would be mixed with the car domain object, which is what OO is about. Mixing behavior with traits (or methods with properties).

The ADM on the other hand mainly separates the domain logic from the domain object, leaving the domain object to be a carrier of nothing but state for the data whilst allowing a separate service layer to perform actions upon those objects. In an ADM, a person object has mainly only properties and become a "reference" object, only containing minimal numbers of methods. Service object then act as components that are able to perform actions on these objects.

However, I think that the anemic domain model has retained and in fact gained some popularity over time for a few reasons. It is true and commonly said that those that come from a data background are more likely to use an anemic domain model as data is at the core of the application for these people. However, it is not just those data modelers that favor the ADM.

The ADM allows clear boundaries between representing the state of the domain and those things that have an acting force upon it. Writing our domain model against a good set of interfaces allows us also to build a useful service layer that can act upon all sorts of domain objects.

Readability in an ADM architecture is also, IMHO an easier task facilitated by the clearer boundaries. In all probability the ADM has become more popular though not just for these reasons, but also because of object responsibility. using an ADM means that one can concentrate on modeling the domain objects for what they are. The job of object responsibility becomes easier in an ADM world because the domain objects only have to concentrate on being themselves and the responsibility of an object is not blurred. How often have we seen the RDM and asked "why on earth has bob put that method in that object"?

So, I like the ADM. When coupled with a decent framework on which to build our web based applications, I find it a tried and tested method that ensures the same maintainability, readability and de-coupled approach time and time again.

Cheers

Rich
Rated Good [4 out of 5]. with 0 Comments