Alt.Net FTW!

I attended an alt.net usergroup the other day. There was a lot of dialog of what alt.net is and if the alt.net movement has already started dying.

It doesn't really matter if there is a movement. Alt.net is more about concept and a way of thinking than it is about a bunch of people. As long as people develop tools and components to use with .net and don't just wait for the next release from Microsoft, the spirit of alt.net will live.

So if you are a .net developer and your primary source of ideas comes from Microsoft then you don't have to care about what alt.net is. If you on the other hand keep looking out for better ways to do stuff, an alt.net meeting might be for you.

Working on collections and searching for objects

I am reading a book about F# which is a functional language for .net. At the same time I have been introduced to JQuery which is a javascript framework for querying and manipulating objects on a html page. It has sprung some ideas for the plain framework.

What I'm striving for is the possibility to query an object structure for objects. When the objects are returned, it should be possible to perform actions on all these objects in one statement. LINQ might be usefull for querying but at the moment I'm guessing that it won't fulfill my needs.

Lets me give an example of what is currently in progress. This will find all TextBox objects that contain the value '0' and set the background colour on it:

form.find<textbox>("[.Text='0']").Do(t=>t.BackColor= Color.Azure);

The .find method is an extension method on object, which means you can use it for any object. The .Do method is an extension method to all IEnumerable<> that lets you perform the lambda function on all instances contained in the list.

Another example is by using the Map method.

IList<string> textboxValues = form.find<textbox>().Map<string>(t=>x.Name +": " + x.Text);

This will produce a list of strings with that name and value of all textboxes somewhere on the form. The Map method is currently not an extension method as I haven't figured out how to implement the syntax of just just providing one generic parameter to an extension method working on a generic type :(
Actually there is a Map extension method, but it requires you to provide the generic type of the collection as well. In this case it would be .Map<textbox,string>(...)

The one thing that is missing is the syntax to search for objects. Will it be LINQ or will it be a homegrown dsl?

If you want to use the .Do method here it is:


public delegate void OneParemeterNoReturn(T x);
public static void Do<t>(this IEnumerable<t> o,OneParemeterNoReturn<t> func){
foreach(T t in o){
func.Invoke(t);
}
}


otherwise you can wait for it to apear in the plain framework :)

Creating overloaded methods with extension methods

I have an interface in an application.

I want the interface to be simple to implement so it basically contains one method that has a number of parameters.

I want the interface to be simple to use, so I have implemented a number of extension methods that will work as overloads for the method specified in the interface.

So far so good. My next wish is to make the interface generic. This is where the everything falls apart. Apparently you are not able to make extension methods on a generic type. Every time i come across such mismatch between part of the .Net framework I am very sad. I wish the next version could just be a little coherent. :(

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.

My Prefered Developer Profile

My preferred coworker has the following qualities:

• Lazy: I want the person to avoid repetitive work. Some might say that repetitive work is part of the job. I think repetitive work is a sign of bad architecture. Repetitive work should be avoided at all costs.
• Rebellious: Don't accept everything I say. I'm just human and might be mistaken. I get suspicious if no one challenges my ideas.
• Geeky: I want developers to be enthusiastic about the work they do. All the time they should be striving for better solutions to the problems we have.
• Have a hobby: Software development is not everything, and a lot of software ideas spring from problems outside this business.

And probably some more :)

Comma Separated Values

Or csv file extensions for tabular data.
I thought the name described the format, and that it was as simple as that. It was only when I tried to read such file in MS Excel I found out it is not the case. Apparently my regional settings requires csv files to be semicolon separated. So much for international documents :)

When to use the GAC

I've been using the .Net framework for a few years now. I still haven't really found a use for it...

One of the good things about .Net is the xcopy deployment strategi. It is kind of lost when the gac is used. With the gac your solutions suddently start to depend upon each other a lot more.

Thanks, but no thanks: No more GAC!

If anyone out there has a good use for the gac, please let me know :)

Consuming generic types as a generic parameter

What is he talking about? Well, I have a hard time expressing myself when it comes to generics. I'm trying to make a library I can use across projects

This is what I want to do:

interface BusinessEntity<T>{...}
class EntityList<T> where T : BusinessEntity<TT>{...}

That way I can let my domain objects implement the BusinessEntity interface and they can be consumed by my EntityList. In the following I have a domain class called Document.

//defining Document
class Document : BusinessEntity<int>{...}
//creating instance
EntityList<Document> list = new EntityList<Document>();

To me this all makes sense. Sadly it doesn't compile :( The problem is that TT in the EntityList is not defined. As far as I know I have to define both T and TT on EntityList even though TT is given once I have defined T. Now it loks like this:

//definition
class EntityList<T,TT> where T : BusinessEntity<TT>{...}
//creating instance
EntityList<Document,int> list = new EntityList<Document,int>();

I'm not to happy about the extra generic parameter on the EntityList. Once T is defined, there can be only one valid type of TT. But because of the way you have to define it, the compiler will not complain about the TT, but actually about the fact that T doesn't implement BusinessEntity<TT>. This means that if TT is defined as string for instance, the error message from the compiler will be: Error, Document does not implement the interface BusinessEntity<string>. This will make no sense to the programmer trying to use the class.

If you have any solution to this, please let me know :)

Platform as a religion

I don't like job titles like "evangelist". I instantly think of religion and that they believe they have found the one true answer they are going to preach to me. I believe solutions only can be measured against real problems, and if the problem is complex and abstract, the outcome can be hard to conclude anything upon.

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