Sunday, April 27, 2008

Extensions methods... Still missing some features

I like extension methods in dotNet. Extension methods give you easier access to your helper and util classes with static methods that operate on your object. It's not that extension methods give you any new features, they just give a little different syntax that might be a little more natural. It gives the programmer a way to use methods across your project without learning the syntax of your helper classes.

I like extension methods because they give me a way of separating my code where I find it fit, and still give the user a feal of coherence. Extension methods do not affect the architecture of your application as it doesn't change where code is, just the syntax of accessing it.

So far I have found 3 areas where extension methods fall short.

1. :
Extension methods can be made work like instance methods. Extension method cannot be used as static methods. In a static context they could have been great for factory methods and such for your classes and interfaces.
IDomainObject o = IDomainObject.Load(1); //Working on the type. Can't be implemented as an Extension method
o.Save(); //working on an instance. This is ok
Wouldn't static extension methods be cool? :)

2.: Extension methods can't overload operators. As I generally dislike operator overlodings, this is not a big problem for me. I do however have one place in mind where I could use this.

3.: Visual studio does not recognice Extension methods if your code is in the class that is extended.
public class Test{
public void doStuff(){
HandleMe(); //Can't be implemented through extension methods
this.HandleMe2(); //This can be an extension method.

I don't really see why this is not implemented. Maybe it will come in a future release.

Extension methods are GREAT!

Friday, April 11, 2008

Creating a test/development enviroment

On most projects I've been on, defining the infrastructure has started by looking at the customers current infrastructure and then trying to create an environment that resembles that for testing and for development. I have never seen a test environment that looks like the production one. I have never moved an application from test to production without some unknown settings on the production environment.

My suggestion is this: We should stop using the production environment as the reference of our development. Instead we should specify the environment in as simple terms as possible. this specification should of course be validated by infrastructure guys (or girls). This way the application developer can focus on what is his does best which is the functionality of the application and not hardware and network setup.

This approach should result in better applications because it lets the infrastructure support the application and not the other way around.

Edit: I had a comment on this post. What I mean is that I want the reference infrastructure to be something that can be realised in a test and development environment. I don't want the production environment to be the reference. The reference infrastructure should of course be evaluated by someone who knows the production environment. Getting the application from the reference installation to the production environment should not be a task for a developer.

Wednesday, April 09, 2008

Databinding in WPF

Data binding in .Net has previouslybeen done by providing a data source and calling DataBind(). It has been a one way data flow initialized directly by user code. In WPF they have changed it a bit. To enable automatic synchronization they have basically implemented the Observer pattern. To make this happen they have implemented the properties in the UI component as DependencyProperties. A DependencyProperty is a static object on the class containing the property. The ordinary properties on the class are wrappers setting the value on the DependencyProperty. In this way you can subscribe to changes on the property through the DependencyProperty.

In the illustration I'm trying to show two connected textboxes. When typing the name of a font in the first TextBox, the font of the second should change accordingly.

This event driven synchronization is dependent on the fact that your object inherits DependencyObject and that your properties use DependencyProperties. If you want your UI to be data bound to something that is not a UI component, you can implement the INotifyPropertyChanged interface and fire the PropertyChanged event when your object changes.

The way to publish data to the UI could be to bind all the fields in the UI in relation to a parent container (the windows or something) and then set DataContext to the data object. This way your UI is filled with data very smoothly.

Sunday, April 06, 2008

Xaml, the ultra lightweight IOC container

I've been testing xaml for defining what object to create at runtime. Although xaml is often linked to windows workflow foundation or windows presentation foundation, it can easily be applied to your own domain.

Xaml is a xml language where you can define how a .net object structure is to be initialized. It has many similarities to, lightweight IOC.

The greatest thing about Xaml is it's very easy syntax. Every node in your xml is giveng the name of the class to instantiate. By givin the root node a namespace, your VS.Net provides full intellisense to what properties are on what classes and what type they are. By making typeconverters for your classes you are able to provide a simple way of creating your simple classes.

What is missing then? Well... Xaml is just a language that enables you to create objects. Because of this it doesn't give you the means of controlling the lifespan of your objects. You can't state that an object should be a singleton for the application etc. If you want that you have to code it yourselfes.

Xaml supports property injection but not constructor injection which means all properties needs a public setter for it to be set by Xaml. Most of my properties already have public setters, but I have to alter a few for them to be xaml enabled.

Another thing I'm missing is the support for generic types. In xaml you cannot instansiate List as an example. In stead you kan implement some xaml interfaces or you will have to make new classes that inherrit from the generic type you want.


I have used my search criteria framework that I introduced in "A use for operator overloading" for testing the Xaml.

The above xaml creates the object structure ressembling the following query: Content = "teste feste" or Title = "teste feste" or (Content="test" and Title="test")

I would also have liked a possibility to cross reference objects (create it once and reuse it multiple places in my xaml), but overall xaml provides a very simple way of creating your object away from your code. Whereas has quite a heavy syntax xaml is very intuitive and will be comprehendable, even for people with no technical background.

Thursday, April 03, 2008

Reflection on Lazy loading

No, I'm not going to reflect on lazy loading. :)

By lazy loading I mean having an object model without all of the objects being loaded (from database) at once. If I for instance have a User object with an Organisation, I don't necessarily want the Organisation object to be loaded when the User is loaded. Not loading everything at once speeds things up because you can control what is retrieved from the database and what is not. Anyway, enough about why lazy load. NHibernate implements lazy loading by creating a proxy class that inherits the class of the object. The moment you try to access your object, the object is retrieved from the database. The object you asked for has been loaded internally in the NHibernate object and it will be transparent to you because all your interaction with the object will be passed on to it

The object model you want

The problem starts when you start to use reflection on your objects. The Organisation object on the User is actually not a Organisation, but a subclass generated by NHibernate. If the object you are trying to access is an ExtendedOrganisation, you can't cast it to the type you want because its type is defined by the reference on your User object.

Because NHibernate caches its loaded object it can be hard to tell in advance whether an object will be a proxy or not. If you ask NHibernate to load a Organisation object, you will get a proxy class object if NHibernate has cached it as a lazy loaded object beforehand.

The objects NHibernate gives you

If you want reflection on your objects that may be lazy loaded, you can make generic method where you also have to give the type. When applying reflection you will have to use the generic type for your analysis. If you object has been loaded with a wrong type, you can make a property that returns the same instance. Because the NHibernate proxy contains a reference to the real object and passes all method calls etc. through you can make it work just by returning "this".

Some of the components in .Net that consume list of objects do this by reflecting on the first object in the list, using this type to handle all the objects in the list. You can overcome this by implementing a TypeDescriptionProvider and registering it like described by Ayende. The problem with this is that it will change the way your types are handled throughout your application. You would no longer be able to have a list of ExtendedOrganisations.
The much nicer approach would of course be to have type aware components through Generics.