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]
