This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

about of the first post of this thread, in the book of "Pro Spring" (excelent book) chapter 12 "Transaction Management" looks that the author used the second way, inclusive the class father will come an abstract class, is useful or smart work in this way???

thanks for advanced

Comment

So where does it start? You have to have a parent service object external to the domain at some point to get the initial parent object, right? Say you're modeling something like a car company. The car company object has stuff like cars, employees, factories, etc.

Would you want to inject Locators for each of the children relationships?

The alternative to injecting those Locators would be for the CarCompany to completely load all of those relationships when it is first instantiated, but that could really get quickly out of hand. You end up with the entire domain graph in memory, which obviously isn't ideal for a large domain.

To get your initial CarCompany object, I guess your model layer has to have a CarCompanyLocator service injected, right? Otherwise, to completely encapsulate the CarCompany, you'd have to have a static method CarCompany.get(), which would mean you'd need a CarCompanyLocator object in the class.

Thoughts? I realize this may have strayed into domain design instead of staying on the original DI service layer injection topic, so let me know if I'd be better off in another forum.

but for the other member of this forum with the book of Pro Spring (the use abstract class chapter 12, is a good practice?, for me looks fine)

for other members without the book, the situation is the next
1: interface declare all methods (business methods)
2:class abstract public abstract class myabstract implements myinterface
but this abstract class really never implements the interface, so which??, the concrete son class
3.:concrete class extends the abstarct class and really implements the methods of the interface , so any amount of son class can extend from the father.

the pojo references to other objects (maybe ado references) is declared and managed in the father class, the abstract

The problem with the first option is that it seems redundant - should you handle relationship caching in your domain model? The second option, though, looks like an anemic model from the inside. From the outside, you still see the same behavior, namely CarCompany.getCars(), for example, but the inside is barren.

If you went to an ORM solution like Hibernate, I would think that you'd want the first option, so that Hibernate could manage that parent-child relationship. You would also have the option of dumping the CarLocator entirely and have Hibernate lazy-load the cars child relationship.

Where do you draw the line with Hibernate regarding injecting locators and letting Hibernate manage the parent-child relationships? Would you maybe have a CarCompany that looks like this:

In this case, you'd have Hibernate manage the factories relationship and then use the DAO for the cars one.

The problem is that I've got a richly-connected domain, and I'm trying to decide where you draw the line between populating the parent-child relationships at object instantiation, whether in the data access object or in the ORM persistence layer, or using locator or DAO services to load those relationships on-demand.

thanks for the reply, i follow the fairly and nice logic of the book Pro Spring, about transactions

if i am wrong, please teach me, share information is a good practice

Manager/Model layer (BO and ADO objects)
1:
for the ADO objects i work using Hibernate, so this consist in one interface myinterfaceADO and its myclassADO (that implements the interface ADO)
here happens the CRUD logic for an entity (Worker,Customer,Payment etc etc)

2:
but for the BO objetcs
same case an interface BO(same methods that the ADO objects for example insertCustomerBO ),
an abstract class (father) that implemts the interface BO (but really the implementation not happens here) that work with the ADO services "interfaces" and lastly a Default class (concrete) that extends from the abstract class and this concrete class really implements the BO interface

so in the abstract BO have the ADO interfaces references and call the ADO methods how insertCustomerADO( ... ) in the concrete class (son of the abstract) maybe could has other methods independently of the father and other concrete class that extends from the same father too, the father should has of course the common methods for all the children, validation and call the ADO methods and other methods necessary for the business