1) Patterns
Patterns are only good if they help you. Sounds pretty silly, but its true. I have seen many projects get caught up in the theory of development patterns and the project ends up suffering because the chosen patterns may not truly be needed in some cases. However I do believe in using the right tool for the job and some patterns really do make a big different in development.

The MVP (Model-View-Presenter) works well with Silverlight as does the MVVM (Model-View-ViewModel). In MVP the Model is the data representation, the View is the visual UI, and the presenter is what makes the 2 connect (and the presenter talks to any services it needs). However a better pattern for Silverlight IMO is MVVM. In MVVM there is a Model and a View, just like with MVP. However instead of a presenter there is a ViewModel. The ViewModel not only controls what the View sees, but it is also what the View is data bound to. In MVP the View is bound to the Model but in MVVM the View is bound to the ViewModel. One big difference this brings is that with MVVM the View can get the data in a different shape than how the Model represents it. Often the classes that return data in applications do not quite fit what a UI (a View) needs. MVVM addresses this by making a ViewModel in charge of what the View displays.

There are many other good aspects of MVVM with SIlverlight too, but I'll hit those in a future post. For now, I just want to make it clear how the right pattern like MVVM can make a positive difference in a Silverlight application.

2) Testability
The Silverlight unit testing framework is available to help with this, if so desired. Its a nice tool that can help get TDD into the Silverlight development process. However, if you simply want to create better tests, at a minimum I recommend using a DI (Dependency Injection) pattern in your development process. An oversimplification of DI is basically stating that each class that will be tested has an interface and the interface can be injected into other classes.

For example, a Service class that goes to get data could be injected into a ViewModel instance. The service class could have an interface IMyService that which has 2 concrete implementations: 1 to get the data from a web service and the other to get the data from a hard coded local list (used strictly for testing and design time). Using DI helps make testing much simpler. I recommend using either Microsoft's Unity tools for DI or using the Ninject tools fr DI with Silverlight. Both are excellent and make testing a breeze.

3) Scalable, Modular, Loosely Coupled
Developing large business applications often means having several different modules that an application can be split into. For example there could be a maintenance module, orders module, and an HR module for a storefront application. It would be ideal to have each module developed by different small teams and snapped into the main application when ready. This would allow each module to be developed on their own timelines and remain independent of the other modules. This modularity and loose coupling compliments scalability, too.

There are many ways to accomplish this type of modularity of design. I have even created my own home grown architecture to do this for Silverlight applications. However if you want a more supported and widely used toolset, Prism 2 might be a great fit. Prism 2 is developed by the Microsoft Patterns and Practices team and it helps address modularity, among other things. It is also easy to use with DI and MVVM, if so desired.

This is just a quick overview of some of the ways you can help design a solid Silverlight business application. There is a LOT more to cover, but I'll leave that for future posts.