Architecting Silverlight LOB applications


This post is an introduction to a series of posts that I will be doing about how we can architect an enterprise data-centric Silverlight application. While Silverlight is a powerful platform to create great interactive user experiences for Web, Desktop (and now) Mobile, it is also Microsoft’s best bet to create a multi-platform, cross-browser technology.

A lot of people think of Silverlight as just another Adobe Flash rival because of the RIA aspects both technologies offer and the strong multimedia support that Silverlight has. While this is true, we can get much more from Silverlight if we think of it as good technology for the software industry in Information Technologies. IT projects are all about manipulation, visualization and understanding data.

Silverlight, which is a subset of WPF (excellent to deal with data through data binding) and still a .NET application, when combined with today’s most popular patterns and some key technologies for software engineering, can be a very productive, straight-forward, reliable and successful technology to build this kind of applications, and at the same time, provide great UX.

In this series of posts I will try to cover key aspects when you are architecting an application that can start small, are meant to last for years and over time evolve into a bigger application due to new requirements and be developed by multiple teams without resulting in a big mess of code that no one ever wants to touch.

Such applications often are built using the following principles:

  • Separation of Concerns
    • The most important principle. Ability to divide and conquer by creating layers in your application that are meant to deal with a specific problem, task or functionality, thus reducing complexity. The rest of the principles are all based on this one.
  • Loosely coupling
    • Ability to create multiple components that can work together but do not depend on each other.
  • Flexibility
    • Ability to respond to future changes, either by completely switching the underlying technology or business needs.
  • Extensibility
    • Ability to create new functionality by extending or reusing existing one.
  • Modularity
    • Ability to create well defined (cohesion) independent business areas in your application that can be evolved separately, integrate with each other and even be deployed separately.
  • Testability
    • Ability to avoid/prevent unexpected bugs by changes or new functionality you make, by testing your application’s logic, behavior or dependencies.
  • Maintainable
    • Ability to quickly find the code you need to change, understand it and change it, even if the one who wrote it in the first place is not around anymore (happens frequently).
  • Reutilization
    • Ability to reduce code by creating components that will be reused by other components that require a specific functionality.
  • UI Independence
    • Ability to switch your presentation controls without breaking neither your presentation logic nor your application logic.
  • Localization
    • Ability to target multiple languages, thus increasing your range of customers.

I’m thinking in starting with an overall architecture, choose the right technologies, build a small application on top of it and then keep composing it. I’ll start with .NET 3.5 and later on move to .NET 4.

See you soon!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s