Fredrik Normén

In my previous Part 1 and Part 2 I wrote how a Presentation Model could be implemented and how to handle Async .calls. In this post I will show you how we can avoid adding code to the Code-behind. In Part 2, I had the following code in the code-behind:

In my previous post I wrote about how the Presentation Model could be implemented within Silverlight 2.0, in this post I will show how we can use Async. calls to Web Services.

In this post I will give you an example how the Presentation Model pattern could be implemented when using Silverlight 2.0. I will not dig deep into the Presentation Model, so if you don’t hear of it or want to read more about it, you can visit this page.

There are different ways of getting data from a Silverlight application, in this blog post I will focus on using WCF. When we use WCF we define DataContract which will be used between the client and the server. It’s relative easy to create a DataContract, here is an example of a contract:

It’s amazing how fast the .Net Community have improved it self the last year. More and more developers and architects start to see how important it is to deliver high quality. More and more are interested in design patterns and principles like S.O.L.I.D. They are also interested in how to keep the code they write clean. I have done some work to validate companies design and architecture decisions, and I have notice that more and more companies want this kind of “validation” from someone outside the company, because they start to see that if they use the wrong design or architecture, they are going to pay a lot of more money than if they had the right architecture from the beginning. The cost about getting a validation is so cheap regarding to how much money they need to spend on rewriting or maintaining, or handling problems when they use the wrong architecture. I will say that companies are smarter now than before ;)

To make sure we have clean code and make it easy for us to maintain, we should try to be lazy and reuse code as much as possible, we should also avoid redundant code. But when it comes to crosscutting concerns, we have to be redundant, or? What code is mostly redundant in our code? I will assume that code to check security and logging exceptions are the most redundant code we write. A method should only do one thing, but we can't skip crosscutting concerns, we need it. So basically several method will do more than one thing. Wouldn't it be much better if we only focus on the core concern and skip the crosscutting concerns when we write our code? How can we skip the crosscutting concerns but still has it? The answer is Aspect Oriented Programming (AOP). The PAG team has a Policy Injection Application BLock (PIAB) which we can use to intercept our crosscutting concerns into our code, we also have Spring.Net and some other frameworks. By using AOP frameworks we don't need to write the same code for logging exception etc over and over again, we will also have a much cleaner code, and our focus will only be the core concern. Oh, I feel so lazy, but why should I spend time to write code that do the same thing over and over again, it's so boring, isn't it :P Are you tired of writing crosscutting concerns over and over again, and do you use AOP today?

Since LINQ was added to the .Net Community as a new wonderful new player, more and more solutions I have seen returns the IQueryable<T> from the Data Access Layer. One reason is to easy create different kind of queries in an easy way and execute them. Some developers use the IQueryable<T> interface to create a light weight interface for the Data Access Layer. It's an interesting solution, but at the moment I don't like it.

I have seen several demos and examples on presentations where the Controllers are more or less used as a Business logic layer and based on the definition of the MVC Pattern, that is not the correct way of using the Controller. The Controller in the MVC is not a replacement of the Business Logic Layer. The Model in the MVC is the Business Logic Layer. The Controllers purpose is to be a contract between the View and the Model, and handle user actions. Think of the Controller like the Web Form's Code-behind, the logic you put in the code-behind can sort of be added to the Controller, the benefit you get by using MVC over Web Forms is that you can now with the MVC write unit test to test "complex" presentation layer code, and it's not easy to write test against the code-behind because it's event driven.