Cross-platform application WPF, ASP.NET, Silverlight, WP7, XAML

Question

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

If so, what is the best way to do this?

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

Any information on these applications will be really helpful!

Answer 1

In general, it is not recommended to share domain models between such applications, since you create hard dependencies between them, i.e. any changes to the domain model will affect all applications, forcing you to synchronize the editions of your web and desktop applications.

I would recommend creating separate models adapted to the specific need for information for each type of application, which, of course, adds complexity, but in my experience this is controllable compared to another scenario.

Not sure about serialization issue, if you use WCF to call services, this is not a problem, it is processed for you.

To populate the domain classes, I would recommend AutoMapper, which I have successfully used in several projects. It can automatically map from one class to another based on names and indicate only exceptions (i.e. field names were not displayed or you need some type of conversion logic) Automapper on github

Answer 2

You can share Common.Domain.dll with all your types between WPF and ASP.net, just by referencing it.

Then you can exchange the same types with the WCF client and server (see examples on the Internet, for example http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server- and-client.html ), which allows a separate application to connect domains.

The most difficult of them is to share them in Silverlight, as AFAIK silverlight uses a shortened .net infrastructure with its own compiler. One trick is to add file shortcuts to the C # classes defined in your Common.Domain.dll, or use portable class libraries (http://msdn.microsoft.com/en-us/library/gg597391.aspx)

Whether all this sharing is a good idea, however, this is a separate issue that depends heavily on your release strategy.

Answer 3

To share a domain model between applications, consider the Microsoft Portable Class Libraries Visual Studio Extension. It contains templates for creating libraries that can run on one or more WPF, Silverlight, and Windows Phone. The resulting compiled .dll can be used on all three platforms.

I used this type of project to share common DTOs between a WCF service and its Silverlight consumer.

To translate between your domain model and DTO, take a look at AutoMapper .

Answer 4

Some suggest that you do not extend the server-side domain model to the client application, but instead generate client objects through the webservice proxy generator and perform matching using AutoMap, but I prefer to follow an approach in which objects are shared by the client through a common DLL. This has various advantages:

Arguments

• No double coding.
• There are no proxy objects for real objects. Thus, the execution penalty has not been fulfilled.
• There is no double check implementation on the server and then on the client side.
• Share utility libraries that reference entity objects. You do not need to write utility libraries for user-created proxy objects again, which is a big pain.
• Design once, reuse everywhere.

against

• The Entity library should be regular vanilla classes. No links to external libraries.
• Cannot delete or rename an existing property.

Now I understand that there are some objections to the fact that server entities receive changes and violate client-side code. But in real situations, when you have a client and a server, you can always send a new version to the client. Even if you do not, you can always change the changes in the entity and introduce new services that send back a new version of objects. Also, the probability of a compatibility violation is low. It only breaks when you delete a property, or you change the name of a property in an existing Entity. This is usually a low probability. In my experience, he basically added new objects to objects. Even if you add new objects to your objects, your old clients with the old DLL structure will still work. It can deserialize SOAP payload data.

So, despite some disadvantages, the pros, in my opinion, outweigh the cons. So, I always have an entity DLL that contains all my entities as POCO and shares it with client applications and the server.

Hope this helps.

Answer 5

There are several options that I know of.

• Define models in your web services, when your applications add a link to the service, you will also receive model definitions.

• Use the link to the file and link your domain files with each project (we are currently doing this with some magic from above for discrepancies between the client and the full .net (use auto-meter or reflection to fill in local objects)

• Do you have domain models in a separate project referenced by each

Answer 6

I would recommend having one very thin domain project that does most of the hard lifting, but still provides a common level for your types of projects (WPF, ASP.Net, etc.).

Since the Domain is designed to work with all types of projects, it cannot contain namespaces that are not available in all your types of projects, it will be difficult.

In order to decide that I am proposing to create a Services project that will provide the advanced functionality of your project, the Domain through the compiler or Services directives can be a namespace with different projects per project type. (This method, when sending says only Silverlight, you send Services.Silverlight along with the Domain and your Silverlight project.) This will reduce the number of compatibilizing directives.

After completing the above projects, you can start creating front-end and application logic for all of your other projects. Then you can use auto-mapper or other tools to match (possibly) view models with models from the Domain .

Having a Domain and Services , which is one layer of all the basic logic, in the future it will be easier for you to extend to other types of projects.