All geek questions in one place

Sharing domain model objects in all solution projects

I always have the same situation when creating my projects. I have a basic domain model (entity model). I added a wcf data service project to help request this model. Now, if I want to use one of the model objects, I need to refer to the domain dll model, and this is not always good, because the project may be silverlight, or I can use the service link, and this is probably the best choice but not a transparent poco object.

Do you have any suggestions for best practice on how I can share a common model, so I can use it with the user interface, remote services ...

Thanks in advance...

+4
source share
4 answers

This is probably not a good idea. But I heard that EF4 supports POCO, so you can just add them to a separate assembly referenced by anyone.

In Silverlight in particular, look at wcf ria services .

0
source

Well, your domain model should be a POCO, not an EF model.

If you use pure POCO, then your domain model project will not refer to EF at all, it is the base .NET class library that can be used by any .NET client.

Use POCO or create a facade between the EF model and your customers, where you can design EF objects in the DTO.

+2
source

What do you mean by domain model? Do you mean only classes created by an EF or T4 template? Or do you mean real-domain objects where the generated classes are combined with another partial class containing real business methods?

In the first case, you can simply exchange the assembly with the client. In the case of a service, it creates a tight connection between the service and the client, which is usually considered bad practice. But there are still scenarios in which WCF is used instead of remote access, in which case co-assembly is a common scenario.

In the latter case, the point: DO NOT ADD domain objects with clients of your services. Domain objects and their methods are intended for maintenance, not for the client. Use custom DTOs or objects created from service help.

If you work with web services, you must follow a simple rule: your model does not cross the physical boundary. This means that the model is internal to the service, and the client does not use it.

+1
source

Some suggestions on how to handle domain model sharing for solutions when at least one Silverlight solution can be found at the following link:

Best practice for common Silverlight and .NET 3.5 code?

0
source

Source: https://habr.com/ru/post/1341552/

More articles:


All Articles