On Mon, Nov 24, 2008 at 12:35 PM, Rob Harrington <[EMAIL PROTECTED]> wrote: > > Hi, > > Digging into AppFuse (2.0.2, modular struts, full-source). > > In this thread Matt seems to be saying there's no value going forward using > UniversalManager over GenericManager.
You are correct. It's been removed in trunk (2.1). > > > >> I also >> believe generics are the better path, but left the old ones in during >> the initial migration in case people liked them. My guess is that no >> one uses Universal* classes and the choice just causes confusion. >> > > http://www.nabble.com/UserManager-and-UserDao-Inheritance-Interface-Mismatch-td19403168s2369.html#a19403168 > > Seems like using GenericManager would require a particular instance of it or > its subclass to be built around a single Dao instance (GenericDao or a > subclass of it) in order for it to work properly for all use cases. > > In the core code I'm not seeing a case where there are multiple daos > injected into a Manager but it seems like that would be a common use case as > the manager methods are the level at which transactions are demarkated (if > that's a word). For instance I might want to make a transaction-based > update to data in 2 separate tables via 2 separate daos. I might not be > able to rely on cascading by passing a particular model object into a > particular Dao. > > So I guess this is more of a general question on what the architectural > design decision is/was here. Am I misunderstanding how GenericManager > works, and/or am I off-base to expect to be able to work with multiple DAO's > from a single manager method? If you don't want to write any code, you can use GenericManager/Dao wired up in Spring. You can also use a Manager and reference several DAOs. I believe the latter will become the more common pattern if/when Managers become APIs. Matt > > TIA, > Rob > -- > View this message in context: > http://www.nabble.com/UniversalManager-vs-GenericManager-tp20668077s2369p20668077.html > Sent from the AppFuse - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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]
