Shared Data Contracts

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Jan 11, 2008 at 10:25 AM
The project I am currently working on will eventually comprise of about 7 services.

The Data Contracts used by these services will contain lots of entities that should be shared across the Services (For example, entities like Currencies, Funds, etc..). However if am creating a "Data Contract Model" per Service, there doesn't appear to be any way of having entities in one model refer to entities in another model. For example, if I am modelling a Client and I need to link in Currency entity and that Currency is defined in a separate model.

So my workaround for this is to just create one big Data Contract Model that is then used by all of the services.

But before I go too far down this route I was wondering:

a) Am I doing the right thing? Have I missed something? Is there a better workaround?

b) Is there any technical limit on the size of a Data Contract Model?

b) Is there any practical limit on the size of a Data Contract Model?

Jan 11, 2008 at 3:19 PM
As far as I know, this is the only way to share DCs between different service contracts models.
On the other hand, I know that you may have several hundred DCs on the same model though you may get a big screen or get some practice with the elements layout to visualize all the model.
Jan 17, 2008 at 11:48 AM
Thanks. I've now moved on a little further and have one big Data Contract Model, and multiple Service Contract Models. That seems fine.

However, I seem to have hit another problem now. As there are now multiple services, I have to add a client proxy for each individual service. This in itself is not a problem. But each service gets its own .net namespace and versions of the shared Data Contracts. So I have the same entities existing under different .net namespaces. This is going to cause a problem if I try to use one entity in place of another (e.g. I get an entity back from one service, amend it and pass it back to another service). Plus it will also be confusing for users of the services.

One thing I can do is manually tweak the .MAP file to get the proxies to all generate to the same namespace. However I then get a clash when I try to compile, as they try to define the same classes more than once. I can resolve this manually by editing the proxy code to remove the duplicates but that is going to end up being a lot of work as they system grows. One option I have thought is to write some kind of add-in/recipe that automatically consolidates multiple proxies into one but that doesn't seem so easy.

Of course, the other option I have is to just have one big Service Contract Model, and therefore just the one service/proxy. But I'm not sure if this is advisable. Do you have any thoughts on this?

Also, is there any official guidance on situations like this where users are developing large enterprise systems with many entities, operations and services?

Jan 18, 2008 at 6:47 PM
If you want to share MessageContracts or DataContracts across client proxies, then you may add references to your defined types (same projects referenced in your services) and use them in your proxies (in this case, you may not use the generated proxies and use dynamic calls where you simply pass your referenced types.
You can find some ideas here:
Jan 18, 2008 at 7:06 PM
Thanks for the reply. This is the route I had just started going down today, as I realised the primary client for these services will be our own WinForms app, so sharing the Service, Message and Data contracts with the WinForms app is perfectly fine.