Wishlist: Derived generic parameters

In .Net generics gives a nice way to make type agnostic code that are not limited to a specific type.

The following two types are taken from the plain framework.

interface IBusinessEntity<T>{
    T Id {get;set;}
}

interface IDao<T,TT> where T : IBusinessEntity<TT>{
    T Get(TT);
    TT Save(T);
}

As shown you can use gemeric types as generic parameters for other types. In the IDao interface, I have specified that T must be a IBusinessEntity interface with the TT type as a generic parameter.
In my example I will create a Article class that implements the IBusinessEntity interface and a generic Dao implementation

class Article : IBusinessEntity<int>{
    //some code
}

class Dao<T,TT> : IDao<T,TT>{
    //some code
}


Now I want to get a dao for the class you just created. As Article has int as a generic parameter, the Dao objects has to defined with the article type as well as int to be able to compile.

var dao = new Dao<Article,int>();

Once you apply "Article", the only valid type as TT is "int". If you apply anything else, the compiler will let you know that "Article" is not valid. The reason for this is that in the definition of IDao, T has a requirement for T, not TT.
It has been bugging me that the compiler complains about the type of T and not the type of TT. T is the important generic parameter, and TT could just be derived from that.

In future releases of .net I would like to be able to write the following.
interface IDao<T<TT>> where T : IBusinessEntity<TT>{
    T Get(TT);
    TT Save(T);
}


This way I could specify TT as part of the signature, but as TT is derived from what type T is, I would only have to specify T when using it.
When creating the dao I could then write.

var dao = new Dao<Article>();

This is a small improvement, but it would remove some strange dependency error when using multiple generic parameters.

Predictability is a key feature

You can run a rally car on ice. You can travel under water. You can create a fast program based on slow components.

This is all due to predictability. While racing on ice you know more or less what friction you will get and what it will take to change direction. You will know how far you need to see ahead to be able to stay on track. If that criteria is met you can go as fast as possible.

On the oter hand, if you are racing on a mixed surface, you have to go slower. While you have traction you have to drive with a big margin to be able to control your skid if you suddently loose traction. While you lack traction you have to drive slower because if you skid around the corners and reach a high friction area you will end up in the ditch. Given the choice I would definately choose the high predictablity over max traction.

If you know all the parameters of a software project up front you are pretty safe. If you know all the parameters up front, you will also be the first in history to do so. Are you so sure of your requiremetns that you can choose components that fulfill your requirements but are not flexible enought to handle requirement changes? Are you so sure of your performance demands that you  can choose components that perform well but don't scale if your demands change?

Flexibility is often a an underrated feature. Its hard to put in sales brochures. Its hard to tell customers that the extra cost is to support their requirements in the future that they are not aware of yet. Often it has to do with how mature an IT project organisation you are dealing with. The more mature it is, the greater the chance of it expecting changes in the future and the more flexibility it wants from its IT systems. My experience is that these changes will amerge before the end of the project and the flexibility will end up saving them money before the project has ended.

To Cloud or not to Cloud, thats not even a real question

I have read a few posts about Cloud computing on the net. Some of them show great fear of this new thing where a computer is not just a computer and a program is not just a program. How do you back up data and how do you keep it away from others?

To me cloud computing is about abstracting away from hardware instances and thereby allowing easier scalling and distribution of computing. Cloud computing is to instance computing as functional programming is to imperative programming or SOA is to system integration. Instead of defining how you want it you must define what the needs of the application are. This could turn out to be a lot more productive than what we have been used to.

I don't nescesarily think that if you go the Cloud way you have to place all of your data somewhere out of control. It might very well be that parts of your application needs to scale well and you can put that part on a Cloud that supports this. Other parts of you application that has other requirements might have to be put elsewhere, maybe even on the cloud on your own network.

Having few dependencies has been a goal in software development for a long time, and now its moving to the hardware platform. This is a good thing as application requirements will hopefuly be much more transparent in the future.

Wrapping objects with interfaces

Have you ever had to map data to or from 3rd party components? Have you ever had to use reflection to access properties or methods you know the signature for on object you dont' have type for at compile time? This has happened a few times for me, especially when I have to deal with webservices defined by autogenerated classes.

My solution to this is to create an interface that resembles the objects I need to handle. I have made a small helper that will make proxy object for you that implements the provided interface and forwards all property calls and method calls to the object you need access to. This is how you can use it.

IMyInterface wrapped = anyObject.WrapAs<IMyInterface>();

Now you are able to create an interaction that can operate on your object. This might also be a way integrate with components you don't want a direct dependency on.

DataSource, To bind it all.

A small step for mankind, but a giant leap Plain.

We have found a way to bind a lot of the stuff contained in Plain together in an easy manner. When designing Plain we focused on few dependencies, high extendability, flexibility and ease of use. The ease of use is the one that can be hard to align with the other.

Plain is quite easy to use but very flexible. Code was however still needed to hook things together. Its no longer so. By using a Plain DataSource for ASP.Net, you are no longer needed to write any code to hook things together. Just place a DataSource on your page and define what domain class it should operate on and point it to the query ( defined in your business layer). The beauty of using a datasource is that a lot of standard .net usercontrols know how to use it to retreive and send data. DataSource objects also contain information about paging and sorting, and your UserControls will be able to take advantage of that just by enabling them to do so.

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

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.

3rd party software

I'm a bit swamped by 3rd party software at the moment.

3rd party components are good in that they provide a lot of functionality that is already implemented and hopefully also tested. Sometimes I don't think using 3rd party components is the best solution. Sometimes the dependencies are large, and the problems created by these dependencies are greater than the benefits gained from using this 3rd party functionality.

I don't avoid using 3rd party components, but I do have some general issues that I address while deciding whether to use a component.

• Transparent
  Although I select a 3rd party component to reuse allot of its functionality, I like to understand what it does. If i understands its functionality on an abstract level, I'm less dependant on the component in the future.
• Few dependencies
  When I choose a component, I choose it for its features and behavior. I don't want to be handcuffed to other products that I don't intend to use. Even if I want to use the other product, I want be the person making that choice.
  
• Expandable
  I want to be able to plug in my own functionality where ever it makes sense. This could mean an event based approach or something based on contracts