This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello everyone... I have a question regardin retrieving information from a database. Ok, let's say I have a person object, which has name, age, address, gender, etc...So I have a case where I need to retrieve all the persons names, so what would be best? To retrieve a collection of person objects and then iterate through it to get the names, or to perform a query, construct a list of names and that's it? I've been doing the first thing, gather a collection of objects and then in the business level, iterate through them and get the information I need. I don't have to go to the database when for example, a user clicks a persons name to see the other data for that person. But I don't know if this may be too expensive. I guess I could figure out that if I am not going to use more information I could just retrieve what I need. But we always try to think in what if the system should be enhanced to support a new functionality. What factors should be taken into account when making a decision of this kind?
Wow, that's an eternal question with no right answer. Welcome to the club! We get a lot of data from mainframes. We work with the mainframe folk to design a request-reply pair of messages. They say, we're reading this file record to get the data you want, and we're getting more fields. Should we throw them in for free? Geeze, hard to say. Chews up network bandwidth, CPU on both ends, but makes the service more generic and quite likely more reusable. Tough call. We build a service on an app server. Do we return exactly the fields needed for screen X? What happens when we move a field or two from screen X to screen Y? Ouch. It's fairly common to have a set of data-only objects that closely match database tables, a set of service objects that handle business requests and maybe set of request/reply objects that are more closely tailored to the client's needs. You might replace the request/reply objects with XML-DOM or strings so you don't have objects so closely tied to your UI requirements. Did any of that click? I'm sure there are many other ways to think about this. What do you think you might try next?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
At www.agiledata.org/essays/findingObjects.html I include a table listing the various ways you can represent the values of a find from a relational database. The important point is that you need options -- sometimes the real object is what you want, sometimes a proxy is, sometimes a data representation is. There are always trade-offs. - Scott