Adventures while building a Silverlight Enterprise application part #5

It's been a while sins part #4 of this series, mainly because I had some distractions from this project, but also because some requirements were still unclear and we had to wait to see how these would impact implementation details. Now that we are a little further in time, I had some interesting discussion about how we should implement our application.

As I promised dsoltesz in part #3 of this series, I would come up with a post on setting up projects for Silverlight. Although we haven't worked out all the details yet, I didn't want to wait any longer, so this post is mainly about what to look for when starting up a large scale Silverlight 2 project.

Your options
So what are your options for setting up a large scale Silverlight 2 development? Obviously there are many ways to go about it, but I will discuss a few common ones and point out why or why not to use some approaches.

1. Use a single Silverlight Application
2. Use a single Silverlight Application with Silverlight Class Libraries
3. Use multiple Silverlight Applications on different pages
4. Use multiple Silverlight Applications and load them dynamically

Combinations of 2, 3 and 4 are obviously possible and may balance out some of the pros and cons for some of these approaches in specific scenarios.

Before going into details of each of these approaches, I would like to point out that when I talk about a large Silverlight development, I'm talking about at least over twenty different 'forms' to call and an extensive functionality being provided in both the service layer as well as in the UI (validations, algorithms, etc).

Use a single Silverlight Application

The upside of things is that this is very easy to setup... and that's about the only upside I can think of. Downsides? Long initial loading, heavy memory load on the client, harder to maintain, harder to reuse parts. This is obviously a no-go for a large application.

Use a single Silverlight Application with Silverlight Class libraries

This is pretty much the same approach as just having a single application, however, it does make it somewhat easier to maintain and a lot easier to reuse parts. If you have a maybe not so large application, this might be worth investigating.

Use multiple Silverlight Applications on different pages

This makes setup a challenge, because you have to consider what to put on each page, but also what information you would need to share between pages, and how to do this. On its own, this approach will give you shorter load times, easier maintenance and lighter loads on the client. Combine it with the previous approach and you also gain the reusable thing.

This is a good approach IF you can come up with a clear way to split up your application in different pages and you don't have to share large chunks of data between each page.

Use multiple Silverlight Applications and load them dynamically

This makes setup a bit less challenging then the previous approach as you don't have to worry about splitting up over different pages. Sharing data however still requires some thinking, although you do keep state when loading different parts of the application. A different problem with this is, that you do load a lot of overhead if you end up with a large number of small applications (say one for each small 'form').

You do get better load times, but also better response times when navigating through the application. Load on the client is smaller, sharing data is slightly easier then with the previous approach and maintainability is better then all the others. Re usability is also better then all the others.

This would be the way to go, as long as you can come up with a decent design and some common ground on sharing data. A decent service layer is also a requirement.

Applications vs Class libraries

This is actually not a typical Silverlight topic, but as a lot of Silverlight developers have a strictly web background, I figure it wont heart to tough the subject. For everything you build there is the choice, do I put it in an application or in class library? Although there is no 'right way' to go with this there are some pointers:

• Is this something I'm going to use in other parts of the development?
• Is this something I might reuse in other projects?
• Is this a custom control?
• Is this not a UIElement?

If any of these questions result in a positive answer (watch the not in the last one and think like a developer ;-)), then you probably want to use a class library. In most other cases you can just put it in an application and you'll be fine.

Solutions

Another part of setting up the project is the solution files. Although Microsoft states that a solution file is developer specific and because of this could very per developer, this is usually not what happens in practice. On the other hand I've seen a lot of developments slow down to a crawl, because they just threw all their projects in one huge solution, that would take ages to load and if someone made the mistake to rebuild the solution, it would take even longer to complete.

Obviously the truth lays somewhere in the middle, so using a few solutions is usually a good idea. How you split them up, however, is very dependent on the team, the tools, the project and also personal preference. In our case, our goal is to have several developers build modules for our application. To make this possible we're building a framework that supports running these modules and provides all the common UI elements and behaviour. This makes up one solution. Other solutions will contain sets of modules that are grouped based on their logical purpose.

We can work with smaller solutions, because we have Team Foundation Server and use a build server to generate releases, so we don't have to worry about manually opening all the solutions, and build them. Also, all our modules have to be able to run without the framework, so we don't have to worry about test runs during development. All we have to do is do integration testing for the modules.

If you don't have a build server, or another form of automated building, then you probably want to cut back on the number of solutions, but always look out for the size. Once a solution becomes slow to load and/or build, think about moving some projects to another solution.

I hoped you enjoyed this article and I'm looking forward to your comments below.