fea jabi wrote: > you have mentioned that > > "You're going to have an object in memory no matter what" > > If we are using Resultset how/when is the Object getting created? I > was under the impression that it will get the data directly from the DB. Uh... a ResultSet is an object. >> You're going to have an object in memory no matter what. In most cases >> DB connections are a more limited resource than memory. Besides, once >> the ResultSet is translated into a DTO, it is free for GC anyway, so >> you've really only lost the conversion time, which is worth it IMO. > what are these DTO, GC and IMO? Data Transfer Object, Garbage Collection, In My Opinion. > I do remember reading somewhere that if this approach is used then > we'll be breaking the MVC architecture. > any reference links for this? Nope. I'd bet Google could help you out here, though.
I'm not sure I'd say using a ResultSet directly breaks MVC... while I'm not sure I'd call a ResultSet a "real" DTO, that aspect of it doesn't relly enter into the MVC equation. MVC has more to do with separation of responsibilities between the business model, presentation model, and how control is delegated. (That was _not_ a good explanation.) Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
