That's how my persistence framework goes. All my data extends a data object which makes public CRUD methods that accept a persister, you can then have File persisters, Database persisters etc. An employee shouldn't have any knowledge of how they persist in an enterprise IMHO. All that logic is placed in the persister.
Employee employee = new Employee(); employee.setKey(1); // Reads and populates an employee. EmployeeDBPersister dbPersister = new EmployeeDBPersister(conn); employee.read(dbPersister); // Writes the employee to a file. EmployeeFilePersister filePersister = new EmployeeFilePersister(file); employee.create(filePersister); I hate DAO's. The company I work for uses them. Basically one class to do all the logic related in any way shape of form to a valgue amount of database tables. They then change a column on a table and wonder why there code is a nightmare to fix. If you have one Persister responsible for a table then you change the four pieces of sql for create read update and delete and you are laughing. In answer to the collections comment, I have managers which my application interfaces with to get collections. Basically something like EmployeeManager manager = new EmployeeManager(); ArrayList employees = manager.getEmployees(); And the method gets all the keys in a separate piece of SQL and then calls the code I have shown above. -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: 04 August 2005 16:15 To: Struts Users Mailing List Subject: Re: DTOs are evil Michael Jouravlev wrote the following on 8/3/2005 9:07 PM: > http://www.theserverside.com/news/thread.tss?thread_id=35233 > Just curious what are Rod's exact views on the DTO? I searched for DTOs on that link you posted but only saw posts by other people. I do agree, though, with what others have said that DTOs/ValueObjects aren't really that OO. It's funny that the subject comes up because I was a late bloomer to the programming world (started about 6 years and was a waiter and science teacher before that:), and when I first started reading the Java books and then applying that to what I was reading/seeing in JSP projects I was on, the concepts did seem to conflict. What I mean is take the concept of an "Employee." In almost all web applications you see the EmployeeDTO being passed to the DAO... employeeDAO.updateEmployee( employee ); From what I recall the real OO way would be... employee.update(); and employee takes care of updating itself. From an OO perspective I don't see a problem having an Employee object that has a DAO inside that takes care of persistence. I do have a couple questions though about OO design if this approach is used... 1) Where do you encapsulate getting Collections back of your objects? For example an Employee object has CRUD methods, but what about you when you need a List of Employees? Do you make an EmployeeList object that has methods getEmployees? Do you maybe just 'cheat' and add a getList or getEmployees method directly to the Employee object? 2) It also seems a bit heavy to return Collections of pretty heavy objects. (Each Employee since it's not a simple VO could be a large object - although by large I just mean having a bunch of methods in it etc - I'm not so sure it would be large footprint-wise if just the properties were being filled in the case of a list - so bottom line is maybe the extra stuff in the object doesn't matter much? Side note... 3) Even from an OO perspective, you always hear about encapsulating unique behaviors to make things reusable, so in a sense couldn't you consider the 'properties' of an Employee 'unique' or, if not the properties, the CRUD stuff is 'sort of' unique? If this is the case, you could make an argument for separating out the properties into another object (DTO/VO) separate? -- Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
