Adventures while building a Silverlight Enterprise application part #1

At the moment our team is in the start up fase of building a complete enterprise applications user interface in Silverlight. As it goes, we obviously run into some challenges and find out things. This series of articles is aimed at sharing our experiences with you, so you may avoid pitfalls, and maybe even get some inspiration from our approach.



In this first installment we would like to have a look at some of the general requirements for our application and how we aim to tackle some of those.



Requirements

The following generic requirements are part of our application:

• Secure! This is a very important requirement for our customers, as data stored is sensitive information


• Scalable. We will provide our application to very different users that will sometimes only use a small part of the application. They will not accept a high load for a small amount of functionality.


• Multi language. We have to support both English and Dutch in the user interface.


• Maintainable. It may sound obvious, but our application changes several times a year.


• Reusable. Again, this may sound obvious, but in our case, parts of the application may be reused in portals.


• Easy high volume data input. Some of the users need to be able to quickly enter large amounts of data.

As you can see, challenges enough! Also, some performance requirements were put down, based on ASP.NET, for loading certain parts of the application.

Right now we would like to take a look at one part of the solution we used: dynamically loading XAP files.

Dynamically loading XAP files

By applying this well documented technique to our application we expect to fill in at least part of the following requirements:

• Secure; As our application is broken down into different parts, based on different functional roles, we only load part of the application based on access rights. So a large portion of code that a user has no access to is not loaded.


• Scalable; As our application is broken down into different parts, it is easier to scale by adding a new part in a separate XAP file.


• Maintainable; As we are working with a team of people, having multiple projects makes it easier to maintain and deploy.


• Performance; This is our main reason to have multiple XAP files. We don't expect to reach our performance goals, if we would use a single XAP file. By only loading XAP files as we need them, we expect to have better performance at application start up and have a smaller footprint of the client (thus better performance).

It also raised some questions that we had to answer:

• Security; We had to pass the security context of the user between applications. Initially we planned to also use multiple pages, thus we would have to pass this context from page to page in a secure way. We decided to have one outer application that is in charge of security context and by using an interface in the loaded modules, it can optionally pass this context to the module.


• Reusable; As it stands, parts of our application are reused trough out different XAP files. This called for a good strategy around using Silverlight Class Libraries and User Controls. We expect this to be a continuous process, trough out building the application.

This first installment didn't contain much technical stuff, I know, but I hope it gave you some insight as to what challenges may arise when you use Silverlight 2 for building an enterprise application. I also hope that this series will show you that Silverlight 2 is actually very suitable for this purpose. Read the next post here.

If you have any questions, thoughts, suggestions, etc. please leave me a comment below. I'm always happy to read and reply to any of you.