Problems with Smart Clients today
My experience is that the Hexagonal approach is the best way to develop smart client applications, or applications that want to have a smart client interface. Typically, you choose a smart client for one or more of the following three reasons.
1) To acheive a more responsive, richer user experience,
2) To enable disconnected use of the application,
3) To enable real-time notification of remote events, (for example, chat, im features).
You can’t do any of these things well using web applications, you need a smart client. People normally decide to go the smart client route because they have one of the above requirements. Although you can (theoretically) do the 3 things listed above with a smart client, you are still left with a lot of work in designing the application to make it actually happen.
In the MS sanctioned smart client design, you have your business logic running behind a web service, which effectively prevents you from giving users real-time validation feedback unless you duplicate your validation logic in the client (not a good idea). You can not deploy the business logic to the client, because it depends on your data access layer, and you don’t want your smart clients connecting directly to the database (for scalability and possibly security reasons). Your smart client can not respond to remote events because you are using HTTP. Finally, if you are using ClickOnce you probably cannot connect to event-services due to code access security. It seems that the only benefit you get from your smart client is the ability to use fancy windows controls, instead of javascript driven simulations.
The Hexagonal Architecture can help you build software that can do all three of the things I listed, while also enabling you to rapidly adjust to changes in business and technological requirements.