Timeline for Return domain objects from the repository
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 5, 2017 at 21:08 | history | edited | RibaldEddie | CC BY-SA 3.0 |
expanded answer due to comments
|
| Aug 3, 2017 at 17:58 | comment | added | Laiv | @w0051977 consider what Robert already commented. If you need both models, call db entities DTO (PersonDTO) or PersonState or PersonEntity. Keep it hidden by the domain model Person because essentially, Person is likely the name that the ubiquitous language is going to use. If you come to the conclusion that there's no need of two models, choose the name used by the ubiquitous language. The domain data model is going to be shaped -quite often- by the language. That's why the language matters in DDD. | |
| Aug 3, 2017 at 17:47 | comment | added | RibaldEddie | My view on this is that if you want to keep the verbiage close to a description of the real world system where a person does place an order, is to consider a concept like an OrderSubmitter or Orderer that may contain a Person or can be constructed from a combination of a Person and another object(s). | |
| Aug 3, 2017 at 17:47 | comment | added | w0051977 | The reason for the question is that the domain objects and entity objects have exactly the same names. There are lots of ways around this, however every single way is criticised on here. Therefore I must be missing something. | |
| Aug 3, 2017 at 17:43 | comment | added | Robert Harvey | @w0051977: This is more than just a naming problem. My instinct is to answer your last question with "Persons don't place orders. An order management object places orders on behalf of the person." See here for some further insight into your overall problem. | |
| Aug 3, 2017 at 17:41 | comment | added | Robert Harvey | @Laiv: I don't think we're there yet. | |
| Aug 3, 2017 at 17:41 | comment | added | Laiv | @RobertHarvey would be good if you could elaborate an answer. For the sake of the question and for the sake of the raised interest that you already generated :-) | |
| Aug 3, 2017 at 17:34 | comment | added | w0051977 | It will be an aggregate root. A person places orders. An order has Order Items etc. | |
| Aug 3, 2017 at 17:32 | comment | added | Robert Harvey | @RibaldEddie: Yes, that's essentially how the two modes work. | |
| Aug 3, 2017 at 17:32 | comment | added | Robert Harvey | @w0051977: What functionality does a Person need to have? | |
| Aug 3, 2017 at 17:31 | comment | added | w0051977 | Do you have an example of a Business Operation class. My experience tells me that I should have a Person class in the domain. | |
| Aug 3, 2017 at 17:30 | comment | added | RibaldEddie | @RobertHarvey when you say two modes, do you mean just the difference between letting the framework generate a DTO-style class from a schema vs writing a class yourself with properties and behavior and then telling the framework to map the hand-written class to a table? | |
| Aug 3, 2017 at 17:25 | comment | added | Robert Harvey | @w0051977: You can't split partial classes across assembly boundaries. If you want to do that, you're better off treating the EF classes as DTO's and using business classes in your business logic layer instead. If you follow domain-design principles, you shouldn't need Person classes in your business logic. Instead, you'll have classes that represent business operations which accept EF Person objects as parameters. | |
| Aug 3, 2017 at 17:23 | comment | added | w0051977 | @Robert Harvey, that sounds good. I guess I could have one partial class in the domain project and one partial class in the infrastructure project? | |
| Aug 3, 2017 at 17:22 | comment | added | Robert Harvey |
@w0051977: If there's no material difference between the Person class in your domain and the Person class in the database, you can probably just add the custom functionality you want to the EF Person class using your own partial Person class. See stackoverflow.com/q/42634184
|
|
| Aug 3, 2017 at 17:20 | comment | added | Robert Harvey | @RibaldEddie: It's two modes for the framework. | |
| Aug 3, 2017 at 17:20 | comment | added | RibaldEddie | What do you mean by DB-first vs code-first? Do you mean how you as the human approach the design in your head or is this some kind of mode for the framework? | |
| Aug 3, 2017 at 17:18 | comment | added | w0051977 | @Robert Harvey, the reason I ask is because the database classes have the same names as the domain classes e.g. Person from the database maps to Person in the domain. How would you distinguish between them if you have both? The options I can think of are: namespaces or renaming all the database tables (in SQL Server) with db at the beginning e.g. dbPerson. The research I have done criticises both these approaches. | |
| Aug 3, 2017 at 17:14 | comment | added | Robert Harvey | @w0051977: I don't think it matters whether it's code-first or database-first. Common-sense approaches suggest a separation between your business logic and your DAL/CRUD component (EF). | |
| Aug 3, 2017 at 17:14 | comment | added | RibaldEddie | @w0051977 so are you saying that you don't know how your framework works? | |
| Aug 3, 2017 at 17:13 | comment | added | w0051977 | I have said that I am using Entity Framework. I am looking for answers with Entity Framework in mind. | |
| Aug 3, 2017 at 17:11 | comment | added | RibaldEddie | My answer is, it depends. It depends on what / how the framework treats these classes. Are they part of a framework specific inheritance hierarchy? Do they contain magic methods added at runtime? If so, then I would avoid treating them as anything but framework specific DTOs. If they are plain old objects that can be instantiated and be useful regardless of the framework then I think it's reasonable to think in the terms of the framework providing a mapping layer between persistence and domain, such that these can be your basic domain entities and contain domain behavior. | |
| Aug 3, 2017 at 17:08 | comment | added | w0051977 | @Robert Harvey, is your comment relating to Database First only or both Database First and Code First? | |
| Aug 3, 2017 at 17:06 | comment | added | Robert Harvey | @w0051977: I wouldn't do that. Just transfer the data from your business objects to the EF objects, and let EF deal with its own objects on its own terms. Put any logic you require into the business objects. | |
| Aug 3, 2017 at 17:05 | comment | added | w0051977 | So it is reasonable to add your own methods to these classes i.e. even the ones' created by EF (in the case of database first)? | |
| Aug 3, 2017 at 16:57 | history | answered | RibaldEddie | CC BY-SA 3.0 |