问题
I'm creating an application which will make use of tables of various sizes, while I have worked on a project labeled DDD before it didn't really get the persistence part right and thus I'm left researching things. One thing I don't fully grasp and can't seem to find concrete examples of is how to persist "children" of aggregate roots. I am working without an ORM (just plain old DAO) which is quite hard to find examples of (this is actually a project for uni which is db specific so I'm 'not allowed' to make use of ORMs, while I appreciate that it would be a lot easier I simply can't). I've looked around for concrete examples on stackoverflow but nothing really seems to describe my particular problem.
I doubt that the code below is right
public DataTable getTableByID(int id) throws AccessException{
DataTable result = this.context.TableContext().getEntityByID(id);
result.setColumns(getColumnsByTableID(id));
return result;
}
private List<DataColumn> getColumnsByTableID(int id){
Object[] arguments = { id };
return this.context.ColumnContext().getUnitsWhere("TABLE_ID = ?", arguments);
}
As you see I set the columns collection every time I retrieve a table entity, which obviously discards any columns already added to or removed from the collection if the table was already in memory. I'm not really sure where or how I should be retrieving the columns (I've considered calling the repository from within the table class but something feels off about that). When it comes to persistence I'm also not completely sure how to go about it, when I add objects to the list I can easily retrieve them but when I remove them I don't really have a way of detecting (cause I'm sure putting events to catch this would be cheating :)). A little push in the right direction would be greatly appreciated, thanks.
回答1:
DDD is a set of guidelines that are technology agnostic. However the projects where domain objects are long lived (i.e. survive process restarts) need some sort of infrastructure to deal with persistence issues, ORM if you use relational database. In such cases ORM is a must because you need your Domain model to be as persistence agnostic as possible. You don't want persistent issues to 'bleed' on your domain model. Now the question is whether you use existing ORM or try to build your own. And it looks like you trying to build your own, whether you realize it or not. Building ORM is a big undertaking, project of its own. I'm not sure how realistic it is to expect one person to build ORM and the application itself in a reasonable amount of time. In any case, Martin Fowler has a set of patterns that you might want to look at:
Object-Relational Behavioral Patterns: Unit of Work (184), Identity Map (195), Lazy Load (200)
Object-Relational Structural Patterns: Identity Field (216), Foreign Key Mapping (236), Association Table Mapping (248), Dependent Mapping (262), Embedded Value (268), Serialized LOB (272), Single Table Inheritance (278), Class Table Inheritance (285), Concrete Table Inheritance (293), Inheritance Mappers (302).
Object-Relational Metadata Mapping Patterns: Metadata Mapping (306), Query Object (316), Repository (322).
For you specific problem look at Identity Map and Data Mapper. You can also look at hibernate sources for the implementation hints but it can be a bit overwhelming.
来源：https://stackoverflow.com/questions/9437792/ddd-java-aggregate-roots-and-persistence