Announcement Announcement Module
Collapse
No announcement yet.
DAO Reference Inside an Entity Domain Object? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Bosmon; well said!

    Comment


    • #92
      Ok - so who's writing a JIRA case for xml version?

      Comment


      • #93
        Thanks for that Bosmon, when my brain and fingers finally join forces I might be able to put it that articulately .

        Glad other people feel like this!

        Comment


        • #94
          Bosmon, +1 on the annotation dependency issue. I too have been concerned by that for a while - albeit only slightly because as you pointed out the convenience has been worth it in most cases.

          Comment


          • #95
            Originally posted by yatesco View Post
            Bosmon; well said!
            Cheers for the props, Colin :P

            So, are you planning to do anything about it, Mister Spring Team? :P

            Comment


            • #96
              After we all agreed and the whole group hug thing.... did anyone JIRA the points raised? If not I'll try and find some time to add it.

              Comment


              • #97
                OK... I didn't really consider that this really was a point that is JIRA-able, but I guess it is! I have written up the basic points as

                http://opensource.atlassian.com/proj...rowse/SPR-2849

                with a link back here.

                Comment


                • #98
                  Hello guys

                  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


                  • #99
                    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?

                    Code:
                    class CarCompany
                    {
                        private List<Car> cars;
                        private List<Employee> employees;
                        private List<Factory> factories;
                        private String name;
                      
                        private CarLocator carLocator;
                        private EmployeeLocator employeeLocator;
                        private FactoryLocator factoryLocator;
                    
                        public void setCarLocator(CarLocator locator) { this.carLocator = locator; }
                        .
                        .
                        .
                        .
                    }
                    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.

                    Code:
                    class CarCompanyLocator
                    {
                        public CarCompany get()
                        {
                            // load the car company from storage
                    
                            // load all the cars
                    
                            // load the employees
                    
                            // load the factories
                        }
                    }
                    Or, you don't put those relationships into the CarCompany object and use the Locators independently to load the objects like Cars or Factories, which leads to a very anemic CarCompany object.

                    Code:
                    public CarCompany
                    
                    public CarCompanyView
                    {
                        private CarLocator carLocator;
                        private FactoryLocator factoryLocator;
                        private EmployeeLocator employeeLocator;
                    
                        public View renderView()
                        {
                            List<Car> cars = carLocator.getAll();
                    
                            // instead of:
                            // CarCompany company = carCompanyLocator.get();
                            // List<Car> cars = company.getCars();
                        }
                    }
                    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.

                    Comment


                    • hello DFielder
                      you first way looks better
                      Code:
                      private CarLocator carLocator;
                      private EmployeeLocator employeeLocator;
                      private FactoryLocator factoryLocator;
                      of course this class should implement an interface

                      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

                      regards

                      Comment


                      • So, do you even model the relationship in the parent class in that case, i.e. with a private data member of type List<Car>, for example? Would your CarCompany look like:

                        Code:
                        public class CarCompany
                        {
                            private List<Car> cars;
                            private CarLocator carLocator;
                        
                            public List<Car> getCars() 
                            {
                                if (cars == null)
                                    cars = carLocator.getCars();
                        
                                return this.cars; 
                            }
                        }
                        or would it look like this:

                        Code:
                        public class CarCompany
                        {
                            private CarLocator carLocator;
                        
                            public List<Car> getCars() 
                            {
                                return carLocator.getCars(); 
                            }
                        }
                        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:

                        Code:
                        public class CarCompany
                        {
                            private List<Car> cars;
                            private List<Factory> factories;
                            private CarLocator carLocator;
                        
                            public List<Car> getCars() 
                            {
                                if (cars == null)
                                    cars = carLocator.getCars();
                        
                                return this.cars; 
                            }
                        
                            public List<Factory> getFactories() { return this.factories; }
                        }
                        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.

                        Thoughts? Anyone else encounter this kind of situation?

                        Comment


                        • Hello DFielder

                          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

                          i work with Struts/Hibernate/Spring

                          i hope that i was failry with this explain, my english is not perfect

                          regards
                          Last edited by dr_pompeii; Nov 24th, 2006, 01:42 PM.

                          Comment

                          Working...
                          X