0

This a question which has baffled me for some time. When I interact with an object in Presentation, how do I find out to which Domain/Business object this relates?

I have Shape classes in my Domain/Business, I draw these Shapes using WPF on the screen (Presentation). So for example I have a class called LineShape in my Domain which I then draw in WPF using System.Windows.Shapes.Line.

Now here is my question, how do I keep the correspondence between the objects in Domain Layer and the Business Layer. Let's say the user clicks on a specific System.Windows.Shapes.Line in WPF, the UI fires an event and gives me the selected System.Windows.Shapes.Line, how do I now recognize which LineShape in my Domain the selected System.Windows.Shapes.Line represents?

I have thought about a few methods, but they do not seem elegant, specially for larger and more complex object models.

  1. Use a dictionary that keeps the correspondence between the Presentation and Domain objects. In this method, when the user selects a System.Windows.Shapes.Line in UI, I can look up the corresponding LineShape in domain in dictionary.

  2. Use an Id for objects both in Presentations and Domain. This sounds a bit strange to me, because as far as I am aware, we are not supposed to use Id for every object in DDD, just for entities.

Are there any best practices to follow here?

enter image description here

Vahid
  • 4,690
  • 11
  • 61
  • 131
  • You would do the drawing by means of an ItemsControl (or a derived control like ListBox), which has its ItemsSource property bound to a collection of domain objects. The presentation objects would be created by DataTemplates, either auto-selected by their DataType, or by the ItemsControl ItemTemplate or ItemTemplateSelector. Like e.g. this: https://stackoverflow.com/a/40190793/1136211 – Clemens Sep 09 '20 at 07:43
  • @Clemens Thank you Clemens, I also thought of that one, making it similar to displaying a list of strings. Of course, the example I provided above is simplified for the question. In a more complex situation, I cannot bind to an ItemsSource, the graphics API can be different than WPF for example, which does not allow ItemsSource. Or there are cases where DTOs come in between the Presentation and Domain. What about these cases? How do I know then the DTO that is now in my ItemsSource belongs to which Domain object? Thanks you. – Vahid Sep 09 '20 at 07:51
  • @Clemens In the link you provided, how ShapeData is linked to the actually Shape class in Domain? Let's say that the user select a Shape in Presentation and deletes it. Now from your approach I know that it corresponds to which ShapeData, but how do I know to which Shape in Domain this ShapeData is linked? Should again the ShapeData reference the actual Shape in Domain? Or have some Id? or...? – Vahid Sep 09 '20 at 07:58
  • "Should again the ShapeData reference the actual Shape in Domain?"- yes, that is the usual reference between view model and model. – Clemens Sep 09 '20 at 08:01
  • @Clemens Thanks for the clarification. If there is a DTO between ViewModels and Models, should then ViewModels reference DTOs and then do these DTOs reference Models? This part seems odd to me because I have not seen any where that DTOs reference Models. How do we find the link then? – Vahid Sep 09 '20 at 08:03

2 Answers2

1

Use an Id for objects both in Presentations and Domain. This sounds a bit strange to me, because as far as I am aware, we are not supposed to use Id for every object in DDD, just for entities.

Perhaps you would be looking at an address rather than an ID. Even values must somehow be addressed so they can be replaced. Such an address may be a class property's name, an array's index, etc.

If you see the whole drawing as a collection of shape values then you could always use the shape's index as the address allowing to replace that specific shape value in the collection.

However, note that the address is only valid as long as you are working against the expected drawing's version.

Furthermore, you could also use the combination of all shape's properties to identify a given shape to modify. If you have two identical shapes (same shape, position, layer, etc.), does it matter which one you re-shape? The final drawing would look exactly the same.

In the end if it makes your life easier to model shapes as entities and given them an ID then perhaps that's the right model too even though you may not care about the specific shape's entire lifecycle.

Finally, note that if shapes are values then you can't possibly keep a reference to them in view models since values are immutable. Also, if shapes are entities, but the drawing is the Aggregate Root then shape entities shouldn't be accessible outside the root. Therefore it most likely only makes sense to reference a domain's Shape in the view model if it's an AR (unless you violate the visibility rule, but still enforce invariants through root-handled events). Also note that address/ID references may be the only option if your domain model lives on another tier.

plalx
  • 41,415
  • 5
  • 69
  • 87
0

You've asked a somewhat broad question, so I will give what I think is a correct but general answer.

In WPF, one way or another, the on-screen controls will have a DataContext. The DataContext generally speaking should be the object you want to get a hold of.

This should be the case more or less regardless of what method you use to populate all the screen controls.

It may suit your program to create special viewmodel classes which bridge between your "native" data objects, in which case those viewmodel classes will be set as the DataContext objects. If you don't need the viewmodel then the native data objects will play that role.

If you are using events, then in the code-behind for the event you can directly access the DataContext property, cast it to the expected type, and off you go.

If you are using commands then generally they are part of the viewmodel object in the first place, so they can just act directly on the object which owns them.

StayOnTarget
  • 9,925
  • 10
  • 45
  • 68