Suppose an object that has like 100 properties, but to create a new object only a few pieces of information are needed.We are using WCF, and I see the following options:1) Use the same domain object for both saving and reading the data. Downside is that it may not be immediately intuitive what properties need to be populated in order to create a new object.2) Create my WCF service call such that I just pass in each piece of information needed as a separate parameter. But what if there were 15 parameters required instead of just 3... or what if the object changes and then it's a hassle to have to update the WCF method signature.3) Create a separate object with only the required properties for saving.I can see that maybe any of these 3 could be a suitable answer depending on the specific scenario. Thoughts?
Domain objects for reading vs saving
domain driven design;persistence
Thoughts? My thought is you are correct, any of these 3 could be a suitable answer. Solution number 2 looks somewhat like the Builder pattern, and solution 3 maybe combined with 2 - create a WCF service which gets the needed information in form of a separate object (a DTO).Besides that, if your domain object has 100 properties, it may be time to question the design of that object (if you are not completely bound to it for legacy reasons).