This is what Glenn Block said during an Interactive Session on Smart Client Software Factory at TechEd Dev 2007.

This is a good news because many of us think that with the arrive of WPF, the effort that MS put on Windows Forms will be null. Fortunately we can go on developing our WinForms application. But…

…I have a doubt.

Why should I choose Windows Forms to start a new project instead of WPF?

WPF is a richer framework, it suppress most of limitations with windows forms, it supports inner property binding, it use the GPU, it separate design from implementation, it is so cool.

I think that every new windows project should start using the new WPF framework, I know that the learning curve is very high at the beginning but this is what I like in our job: keep learning.

The only _real_ problem today with WPF is the lack of a good designer, even the new integrated designer of VS2008 is not to an acceptable level and often you have to code in XAML (which is not so simple). By the way is only a matter of time.

So I agree that Windows Forms is not dead (yet), but in the next few years I think that only few people will use it.

I would like to say a little thing about DTO.

With the advent of LINQ most of the things that I wrote in my old post are not necessary anymore. With the new C# 3.0 is not necessary to build a custom new class for every DTO, you can use the capability called Anonymous Type to create new types on the fly.

Take as example the (usual) case of Customer Address objects, and as the lasts post we want to show on a table the list of Customers with their FullAddress.

With LINQ is not necessary to write a new CustomerDTO class, you can use the following code to obtain the same result:

This snippet create a new Anonymous Type with two properties (Name and FullAddress) without the need to create a custom class.

The TechEd Developer is finished.
This was an intensive week with a lot of interesting contents. These are some of the key points:
1) The ASP.NET MVC Framework is really what I was waiting and it will be available as CTP in December.
2) Small is beautiful: this is the message from Pat Helland in his vision of the future
3) LINQ is not only useful for writing query, there are some other useful way to use it (stay tuned on this blog)
4) System.AddIn is the new namespace that you should use if you write application that support plugin in .NET Fx 3.5
5) Visual Studio 2008 will be available to MSDN Subscriber at the end of November
6) Roy Oshevore is a great songer and even a great developer

This post should close the DTO (or ObjectView) series

In the last post I shown an elegant solution to the DTO implementation using a class that wrap the Domain Model Objects. That solution is, for what I seen, the most used but in this post I would like to show a third possible implementation.

The only little thing of the wrapper solution is that the DTO depend from the Domain Model Oject because internally it has a reference to the Employee class. To remove this dependency we could design a class that contains only the properties to use on the User Interface without the reference to Employee. For example:

    public class EmployeeDTO
    {
        private String _name;
        private String _fullAddress;
      Â
        public String Name
        {
            get { return _name; }
            set { _name = value; }
        }
  Â
        public String FullAddress
        {
            get { return _fullAddress; }
            set { _name = _fullAddress; }
        }
    }

This solution provide a purely container object that has no reference to the Domain Model. But it raise another little problem. Who fill this class with the right data? The service layer is responsible to transform the Domain Objects in these DTOs and a lot of mapping code should be written.

So as usual theres no one best solution, every context has it’s right solution.