Carlos,
If you could start this, it would be great. I'll try to help, but since
I've never used OJB don't expect much :).
-James
On Sun, 2004-12-05 at 01:07 +0900, Carlos Villegas wrote:
> Yes, I don't think we need an IoC framework at this point, at least OJB
> doesn't require it. If it is ok I can take a look at OJB and at least
> determine how much work it's required, maybe get started setting up the
> build system and the beginnings of the code.
> More or less, the following is how to work with OJB and you can tell me
> if this sounds right.
> We can reuse the current db schema. A bean (POJO) is created for each
> table to map to. The build system can use xdoclet to annotate the beans
> so that most of the OJB configuration can be generated automatically as
> well as the initialization code for the database using Torque. This
> means that the SQL scripts are not needed anymore, they can be generated
> from the beans using Torque and xdoclet. Torque and xdoclet are not
> needed for runtime, only for building. The new RDBS store can be written
> by translating one of the current db adapters to OJB. This is
> straightforward. The only thing that I'm not sure is the transaction
> stuff. In a simple way, it can be done the same way that the current
> RDBMS store does it, but OJB is also able to enlist itself in the
> current JTA transaction. So it's possible to take advantage of that.
>
> Carlos
>
> James Mason wrote:
> > Well, Cocoon works pretty well, and it's based on Avalon (another IoC
> > framework, though supposedly not as light-weight as Spring). From the
> > little I've worked with Cocoon it seems to work fairly well.
> >
> > -James
> >
> > On Sat, 2004-12-04 at 00:25 +0100, Oliver Zeigermann wrote:
> >
> >>Hi John,
> >>
> >>thanks a lot this really makes sense to me. Thanks for explaining with
> >>this simple example.
> >>
> >>I was just wondering, does this really work? For real? Isn't it too
> >>complx? Can you still debug this? Why having all these different
> >>implementations? Maybe I am too suspicious, but I am always alert when
> >>I hear introspection, AOP and magic.
> >>
> >>Thanks,
> >>
> >>Oliver
> >>
> >>Anyway, as other people know I am no friend
> >>
> >>On Fri, 3 Dec 2004 13:55:00 -0500, John Gilbert <[EMAIL PROTECTED]> wrote:
> >>
> >>>The key is to code to interfaces and pojo objects as much as possible
> >>>and rely on the framework to find the implementation. This way the
> >>>business logic is fully decoupled from the platform. For example, a
> >>>junit test could be written to test the business logic without the app
> >>>server.
> >>>
> >>>Here is an overly simplified example. Basically, my pojo and action
> >>>classes can be run anywhere. The interface impl is plugged as necessary.
> >>>
> >>>class MyPojo {
> >>> private String name;
> >>> public String getName() { return name; }
> >>> public void setName(String name) { this.name = name; }
> >>>}
> >>>
> >>>interface MyService {
> >>> public doTheWork(MyPojo pojo);
> >>>}
> >>>
> >>>class MyServiceJdoImpl implements MyService {...}
> >>>class MyServiceHibernateImpl implements MyService {...}
> >>>class MyServiceEntityBeanImpl implements MyService {...}
> >>>class MyServiceTestImpl implements MyService {...}
> >>>...etc...
> >>>
> >>>// the spring framework reads its descriptor file to determine the right
> >>>
> >>>// service implementation and uses some combination of introspection and
> >>>AOP
> >>>// to call setService() on the action.
> >>>// This is the magic I haven't delved into yet.
> >>>class MyAction(...) {
> >>> private MyService svc;
> >>> public void setService(MyService svc) {...}
> >>> public ... execute(...) {
> >>> ...
> >>> svc.doTheWork(pojo);
> >>> ...
> >>> }
> >>>}
> >>>
> >>>// in my unit test I can do all the setup and test the functionality
> >>>// or use spring here also I think.
> >>>class MyUnitTest {
> >>>
> >>> public void testService() {
> >>> ...
> >>> MyAction action = new MyAction();
> >>> MyService svc = new MyServiceTestImpl();
> >>> action.setService(svc);
> >>> action.execute(...);
> >>> }
> >>>}
> >>>
> >>>How did I do? Does this make sense? I definitely like it as a design
> >>>pattern, but I'm not completely sold on needing a full framework for it.
> >>>
> >>>The jury is still out. But, it does sell a lot of books. ;-)
> >>>
> >>
> >>---------------------------------------------------------------------
> >>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]
> >
> >
>
>
> ---------------------------------------------------------------------
> 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]
