Thursday 10 December 2009
Excellent post about CQRS by Udi Dahan
Udi Dahan has published an excellent blog post about Command Query Responsibility Segregation. This is a really interesting approach of software development, and I tend to follow that approach in my NetworkMonitoring system.
Wednesday 9 December 2009
The power of patterns
The user interface is one of the most important parts of an application, at least for the end user. It is also the part of the application that will change a lot during the life cycle of an application. Sometimes I even think that you can just make some changes in the user interface and call it a new version of the product and users will be happy.
So to be able to change the user interface without much trouble is a must. But with a lot of applications I saw, this is not possible.What is the problem? The user interface contains to much logic.
This is a problem that many people had and there are some easy ways to solve this...
Patterns
When a couple of people found the same problem and a solution for it, we can call of a pattern. A pattern is just a description of the solution and not the solution itself, so most of the time you have to modify the pattern a little bit to make it work efficiently in your own situation.
A pattern we can use for our user interface problem is the Model View Controller (MVC) pattern.
In MVC we have the Model which is just the data that is requested by the user. The View is the actual form that shows the data from the Model and it will send actions from the user to the Controller. The Controller is responsible for giving the View the right data and update the Model. When the Model is updated it will send a notification to the View and the View will update itself.
Now this is a basic and fast description of MVC and there are a lot more (and better) descriptions on the internet and in books ;)
The 'problem' I have with MVC is that the Model sends updates to the view and the view knows a lot of the Model. And I am not the only one, because there is an other pattern called Model View Presenter (MVP) which is basically a decoupled version of MVC. The Role of the Model is the same, but the View only shows data which it gets from the presenter, and it doesn't update anything by itself. The Presenter has a bigger role, whenever an action is performed it should update the data on the view. It could be frustrating, but it makes the view (user interface) easier to understand/change.
Changing the user interface
Using this patterns makes it really easy to change the user interface, we can easily make a new view and add it it to the Presenter. How these are coupled is basically a matter of taste. I tend to go for Dependency Injection, but it is also possible to give the Presenter a little more knowledge and let it create the view manually.
Although I am not sure about it because I never tried it, I think the MVC pattern family make it easy to change from a desktop application to a web application. There will be some changes in the infrastructure, but in the presenters and the models there shouldn't be much differences.
Testing the presenters
Testing the user interface is difficult, and testing logic in the user interface even more difficult. Using the MVC pattern makes it pretty easy to test at least the most of the logic since the logic is inside the Presenter. We can create a simple version of the view to test whether information is send to it and we can use it to see if the events are working.
So the only not tested parts of the system are the actual views, these should be tested by humans because automated tests will be to complicated (although there are tools who can do this...)
Conclusion
When you have a problem and don't know how to solve it, it is great to be able to find a pattern that describes a possible solution. The problem is that you should have seen the pattern before you know that you can use it. That was basically the purpose of this post. I introduced you to the problem of a fat UI and I mentioned a pattern that could solve the problem. But there are a lot more patterns you probably wan to know about. Therefore I want to redirect you to a few sites:
So to be able to change the user interface without much trouble is a must. But with a lot of applications I saw, this is not possible.What is the problem? The user interface contains to much logic.
This is a problem that many people had and there are some easy ways to solve this...
Patterns
When a couple of people found the same problem and a solution for it, we can call of a pattern. A pattern is just a description of the solution and not the solution itself, so most of the time you have to modify the pattern a little bit to make it work efficiently in your own situation.
In MVC we have the Model which is just the data that is requested by the user. The View is the actual form that shows the data from the Model and it will send actions from the user to the Controller. The Controller is responsible for giving the View the right data and update the Model. When the Model is updated it will send a notification to the View and the View will update itself.
Now this is a basic and fast description of MVC and there are a lot more (and better) descriptions on the internet and in books ;)
Changing the user interface
Using this patterns makes it really easy to change the user interface, we can easily make a new view and add it it to the Presenter. How these are coupled is basically a matter of taste. I tend to go for Dependency Injection, but it is also possible to give the Presenter a little more knowledge and let it create the view manually.
Although I am not sure about it because I never tried it, I think the MVC pattern family make it easy to change from a desktop application to a web application. There will be some changes in the infrastructure, but in the presenters and the models there shouldn't be much differences.
Testing the presenters
Testing the user interface is difficult, and testing logic in the user interface even more difficult. Using the MVC pattern makes it pretty easy to test at least the most of the logic since the logic is inside the Presenter. We can create a simple version of the view to test whether information is send to it and we can use it to see if the events are working.
So the only not tested parts of the system are the actual views, these should be tested by humans because automated tests will be to complicated (although there are tools who can do this...)
Conclusion
When you have a problem and don't know how to solve it, it is great to be able to find a pattern that describes a possible solution. The problem is that you should have seen the pattern before you know that you can use it. That was basically the purpose of this post. I introduced you to the problem of a fat UI and I mentioned a pattern that could solve the problem. But there are a lot more patterns you probably wan to know about. Therefore I want to redirect you to a few sites:
- http://martinfowler.com/eaaDev/ - Application Architecture patterns, very interesting to read
- http://sourcemaking.com/design_patterns - a site that describe some basic design patterns
- http://www.dofactory.com/Patterns/Patterns.aspx - an other site describing basic design patterns
Subscribe to:
Posts (Atom)
