This is the beginning of what’s going to be yet another series focusing on developing LOB applications with Silverlight. I’ve been wanting to write more on this topic since NTK, but there was always something else… In the series, I’ll build a sample application, similar to what I’ve been presenting on NTK. Each post will focus on a specific area, technique or a trick, and show the actual implementation in the sample LOB app, following different patterns I’ve been using in application development in past couple of years. Any comments are welcome.
In this first post, we’ll set up the initial environment for the sample app and write a few words about sharing entities between client and server. This has already been discussed a lot, so I won’t get into greater detail, I’ll just focus on the main points.
Creating a new project
When creating a new Silverlight project, Visual Studio will ask you about creating the accompanying web project as well. The web project will host our data services so it’s kind of important to leave it be.
Adding the entities projects
Create two projects that will host the shared entities. One project will be referenced from the web project (server side), while the other one will be referenced from the Silverlight project (client side). Entity sharing is done in two steps. First is the physical sharing of the files – the “main” entity project would contain the original entity files, while the “supporting” entity project would only host copies of the entity files. Choosing “Add as Link” option in Visual Studio’s Add Item dialog will create a “copy” of the original file, meaning that you’re going to have to change the contents of the file in one place only, while it will be compiled in two different projects.
A couple of notes:
- I usually choose the server side entity project to include the original files, and the client side would include the linked files.
- When adding new entities to the main entity project, add the linked files to the other project before regenerating the service proxy; creating the proxy before that will make a proxy copy of the entity class which may result in some confusion when working with that entity.
- It’s a good thing to declare your entity classes as partial, because you can later extend them with specific functionality on either server or client side.
- When I started on my LOB apps several months ago, I had the following rule regarding marking entities with WCF serialization attributes: when all properties are going to be serialized, don’t mark any; when at least one shouldn’t be serialized, mark those, which should be. Later in the project I found out that it’s much more future-proof and consistent to always mark properties with proper serialization attributes.
- As I’m seeing this is not a general practice with Silverlight developers, I still always separate the WCF contract (interface) from the service implementation. We’ll se how/if we can benefit from such approach later in the series.
So far, the solution looks like this:
We started with a single entity called Person and the DemoService will be used to access the “database”. To keep it simple, the Database class will pose as an in-memory database.
Creating the client
The sample app uses a typical MVVM approach – a ViewModel, instantiating a service proxy and handling the communication with the service, with a View, responsible for displaying the data. The user can browse through the list of persons by clicking their name in the ListBox, while full details are being displayed next to it. I’m not using any real commanding yet, ListBox’s SelectedItem is bound two-way to appropriate VM property, which is also the source for the detail UI. All-in-all, very basic and common setup, which will be the starting ground for all next articles in the series. In the next part, we’ll add a support for editing a Person entity.