A cross-platform application WPF, ASP.NET, Silverlight, WP7, XAML

Question

Considering the fact that all applications will interact with the web project (which will use the cloud or web services).. Is there any way to share my class models between applications?

If yes, what is the best way to do it?

About sending / receiving data from the Webservice, serialize and deserialize, how can I do this in a simple way without having to manually populate the objects?

Any information about this applications would be really helpful!

Answer 1

In general it is not a good idea to share domain models between applications like this since you are creating hard dependencies between them i.e. any change to the domain model will affect all apps forcing you to synchronize releases of you web- , phone- and desktop apps.

I would recommend creating separate models that are tailored to the specific information need of each application type, this adds complexity of course but in my experience this is manageable compared to the other scenario.

Not sure about your serializing question, if you use WCF for calling the services it is a non issue, it's handled for you.

For populating your domain classes i'd recommend AutoMapper, which I've used successfully in several projects. It can automatically map from one class to another based on names and you only specify the exceptions (i.e. were field names don't map or you need some type of convert logic) Automapper on github

Answer 2

You can share a Common.Domain.dll with all of your types between WPF and ASP.net by simply referencing it.

You can then share those same types across a WCF client and server (see examples online, such as http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html) allowing the separate app domains to communicate.

The hardest one is sharing those in Silverlight as AFAIK silverlight uses a cut-down .net framework with it's own compiler. One trick is to add file shortcuts to the c# classes defined in your Common.Domain.dll or to use portable class libraries (http://msdn.microsoft.com/en-us/library/gg597391.aspx)

Whether all this sharing is a good idea however is a separate question, which is highly dependent on your release strategy.

Answer 3

For sharing a domain model between applications, look at Microsoft's Portable Class Libraries Visual Studio extension. It contains templates for creating libraries that can run on one or more of WPF, Silverlight, and Windows Phone. The resulting compiled .dll can be used on all three platforms.

I have used this project type to share common DTOs between a WCF service and its Silverlight consumer, among other things.

For translation between your domain model and a DTO, take a look at AutoMapper.

Answer 4

Some suggest not distributing your server side domain model to the client application instead generating client entities via the webservice proxy generator and doing the mapping using AutoMap, but I prefer to stick to the approach where the entities are shared with the client via a shared DLL. This has various pros:

Pros

• No double coding.
• No mapping proxy objects to real objects. Thus no performance penalty.
• No double validation implementation once on server and then on client side entities.
• Share utility libraries that reference the entity objects. You don't have to write utility libraries again for the client proxy generated entities, which is a big pain.
• Design once, reuse everywhere.

Cons

• Entity library has to be plain vanilla classes. No reference to external libraries.
• An existing property cannot be removed or renamed.

Now I understand there are some objections about server entities getting changed and breaking client side code. But in real life situations, where you own the client and the server, you can always ship a new version to client. Even if you don't do it, you can always version the changes to the entities and introduce new services that sends back new version of entities. Also the chance of breaking compatibility is low. It only breaks when you remove a property or you change the name of a property on an existing Entity. That is usually low probability. In my experience it has been mostly adding new properties to entities. Even if you add new properties to your entities, your old clients having old entity DLL will still work. It can stll deserialize SOAP payloads.

So, despite some cons, the pros outweigh the cons, in my opinion. So, I always have a entity DLL which contains all my entities as POCO and share it with client apps and the server.

Hope this helps.

Answer 5

There are a few options i know of.

1. Define the models in your web services, when your applications adds a reference to the service you will also get the model definitions.

2. Use file linking and link your domain files to each project (we currently do this with some magic on top for the discrepancies between client and full .net (use a automapper or reflection to populate the local objects)

3. Have you domain models in a separate project referenced by each