On Feb 2, 2008 8:04 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > On Feb 2, 2008 11:13 AM, Robert Burrell Donkin > <[EMAIL PROTECTED]> wrote: > > > i now wonder whether it might be better to aggregate backend classes > > according to the technologies they use. so (for example) any backend > > code that uses torque would be in a torque-backend module, any code > > that uses avalon to store data in a avalon-backend module and so on. > > any backend implementations that just use java would be moved into a > > base-backend module. > > I liketo use a pattern that has agnostic API interface module and has > technology specific implementations. > Then for service X you could have X-torque-impl or X-hibernate-impl > etc. You can then also have technology specific shared code, which > might be used across the same technology for a number of different > module impls and anything that is technology neutral is util code for > the API. You kind of get two hierarchies, one functional one > technological. > > Does that make sense in this context? It preserves the "purity" of > module splits by function, but also allows for the need to support > different technologies in implementation.
this was my first intention this will produce a very finely grained component model with lots of modules most with a handful of classes in. inevitably, library code will need to be shared between implementations which use the same technology. so, library modules will also be needed. this will add up to a *lot* of modules. it can be hard to understand systems with scores of modules. whether this is reasonable depends a lot on the granularity of the API components. even then, it may be necessary to be bold in completely decoupling areas of the server and moving them into separate projects completely de-coupled from server. for example, we might need to move mailbox (IMAPs, mailbox managers etc) into a completely separate sub-project. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
