Statefull SOA

I am attending a course on WCF (Windows Communication Foundation).

State full services are sometimes not considered 'right' when speaking of Service Oriented Architecture (SOA).

My claim is that state has nothing to do with whether a service can be a good entity in a SOA architecture. You might have a strategy that your services should bee RESTfull, but that has nothing to do with whether your architecture is service oriented or not. REST gives you some other properties (quite useful I might add), but doesn’t influence the architecture towards SOA.

The same goes for callbacks. Even though my telephone company allows people to call me on my phone, I still consider my phone connection to be a service provided to me by my phone company.

Plain Validations

For field validations we wanted to avoid the implementation of validation duplicated and spread out over several layers of code.

The right place for validation code would be in the business layer. Actually with plain its more of markup than actual code. What we did was to make an interface for validation attributes to implement. When you need to know if your object is in a valid state, you can ask plain and it will pick up your validation attributes and validate your object. This can be done from your user interface layer or anywhere else you might need it.

As plain just needs you to implement an interface there is no limitation to what kind of validations you can create and have plain use to validate your objects.

We are currently working on a way to define validation messages for each validation and a way to have UI use the validations directly on input fields.

Mapping the domain to the web UI

With Plain we wanted some way simple to get data from the domain model to the UI and back.

We already had a mapping implemented from a previous project that could map properties to fields in the UI. What we wanted to change was the dependencies and flexibility of the mapping. Currently all we have to do is name the fields on the form and tell the system what object type to work on to provide CRUD out of the box with plain.

We have one thing left to do on the mapping part. We want lists of values to be filled out automatically. Our Validation component might be what we need to use to be able to do that. More on the Validation component in another post.

Just Plain

I've been working on a small application framework together with a friend. The framework is for developing business applications. I will probably post some stuff about this in the near future. We made it with the following requirements.

• Simple - This is the main purpose of making a framework anyway
• Transparent - We want you, the user of the framework to be in charge and control of what is going on.
• Reduce redundancy - We are strong believers of DRY (Don't repeat yourself)
• Introduce as few dependencies as possible - use what you like, ignore the rest.

The reason for wanting these properties in our framework is as follows. The simple part is easy. We want the interface to be intuitive to use. To accomplish this we choose the simple path over the complex. If something is complex, why not make it without the frameowrk.

In order for you to control what is going on we want to make the framework as transparent as possible. We want the users to be able to do all the same things without the framework, but provide a shortcut by offering a default architecture.

Reduce redundancy means that we want to provide the users of a way to write their code once. As an example this means moving definition of queries from the data layer to the business layer. This way there is one place to make changes, and you don't have to reflect your changes through several layers of code. The data layer is all of a sudden less important, and so is the UI layer. This means that we can supply you with a generic data layer or a ui layer (no layout), and all you have to focus on is your business layer.

By having very few dependencies we remove the reason not to use parts of the framework. Even if you are using large API’s with very strong dependencies and requirements, you can easily use parts of the framework where ever it makes sense and your other dependencies allow it.

The Framework is of course just named Plain

Real Life Dependency Injection

When making a framework you come across the question of how to instantiate your objects, and how the users of your framework can inject object in the framework. Often you want it to be flexible enough for it to be easy to inject object into, but fluent enough for the programmers not to notice the low dependency barrier.

What we did was to make a static application class with a reference to a configuration object which is only loaded once at application start. The application class initiates the configuration object by running a xaml file through the xaml parser. This is a very pragmatic solution that can be used for initialization of static objects in the application. Everything is hooked together with very little code and it can easily be extended to support more objects etc. in applications using the framework.

When the user needs access to any of the injected object he can do like this:

Application.Config.DaoFactory

Although this only supports "singleton" objects it gives me the flexibility I was looking for.

class recommended over interface

I just pulled the Framework Design Guidelines down from the bookshelf to look at it again. I briefly browsed through it and I must say that disagree with it all the same places as last time I read it. At one point they recommend the use of abstract classes over use of interfaces when making a framework. The reason would be that it's easier to add new methods to the framework later without breaking code build on the framework.

I recommend interfaces over classes when designing a framework. Interfaces give fewer dependencies if you have the choice. Like everything else its dependent on the situation what to do.

The book states what you should do and what you should not. Framework design to me is not so black and white. The book is probably more a description of what practices the .net team followed while designing the .net framework. The book is good for developers with little experience, but it seems a little trivial for experienced developers.

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!

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.

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.

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 springframework.net, 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.

Missing?
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.

Example

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 spring.net has quite a heavy syntax xaml is very intuitive and will be comprehendable, even for people with no technical background.

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.