I have a design concern now.
Say we have some hypothetical beans UserManager, PortfolioManager, and, of course, DTOFactory (implemented as a SLSB).
XXXManager beans act as a facade to entity beans. Now, when we need to get a custom DTO for a group view (thus, we need info both from User and Portfolio entity beans), should we go with DTOFactory communicating directly with entity beans bypassing facades or should it talk to them _through_ facade.
Assume that we need almost every field from entity beans, but any ideas are welcome.
It's perfectly acceptable to have a DTO factory or assembler get data directly from entity beans, session beans, DAOs, or any combination of the above.
I think it's really more of a question of what value do these facades or session beans add vs going directly to your entity beans. Do these facades add some transaction, security, or other logic that you need? If so then you should consider using them to avoid any code duplication. Now on the other hand... these facades / session beans may add a lot of logic that you don't need or want -- so going directly to the entity beans may be more appropriate.
Sometimes (if I'm sharing entites across multiple facades) I find it useful to wrap the entity with a simple Session Bean wrapper that has no security constraints, little logic, and basic transaction scope attributes (supports, required, notsupported). Any Facade needing the entity would always go through this SB wrapper class -- adding additional transaction scope and security attributes that work the given SB wrapper into the desired use case.
can i use a dtoAssembler to return all values from one table in my database as a 'big dto', or return the values of a find-method. Which means wrap multiple rows as one object.
Or is an assembler only used to get data from 2,3,... different tables of a database which is related to eachother and combine it as composite DTO. Or in other words, combine one row of each database to one big object.
Or doesn't it matter?