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. ;-)
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Friday, December 03, 2004 1:13 PM
To: Slide Users Mailing List
Subject: Re: developers: table prefix
This may be OT, but I haven't found anyone yet who could explain an
idiot like me what the fantastic benefits of IOC are. Can you?
Oliver
On Fri, 3 Dec 2004 11:31:30 -0500, John Gilbert <[EMAIL PROTECTED]>
wrote:
> Springs big play is its IOC framework. (Inversion of Control) I'm new
to
> it, but so far I haven't found anything in it that I couldn't whip
> together on my own. However, I am a big fan of the IOC design pattern.
>
> It has Hibernate and JDO support for using IOC to plug in
> implementations.
>
> I have recently been using JPOX JDO and the xDoclet JDO tags and Ant
> tasks to generate my JDO files and to enhance my POJOs. So far so
good.
> I really like the fact that it will dynamically generate db schema for
> me. I believe it has a way to resolve table name conflicts.
>
>
>
>
> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 03, 2004 11:02 AM
> To: Slide Users Mailing List
> Subject: Re: developers: table prefix
>
> Has anyone got any idea what role Spring would play in all this???
>
> Oliver
>
> On Fri, 3 Dec 2004 16:57:42 +0100, Oliver Zeigermann
> <[EMAIL PROTECTED]> wrote:
> > Some sort of very short pratcial OJB introduction at :
> >
> > http://blogs.codepuccino.com/dude/index.php?p=23
> >
> > Oliver
> >
> >
> >
> > On Fri, 3 Dec 2004 16:24:35 +0100, Oliver Zeigermann
> > <[EMAIL PROTECTED]> wrote:
> > > I would definitely be +1 for moving to a ORM tool. There is *soo*
> much
> > > maintenance with all these different dbs. As Hibernate is no
option
> > > *right now*, and I have zero experience with OJB I had a lookt at
> > > ibatis. It's nice, but it is an SQL mapper only and can not help
us
> > > with different dbs :(
> > >
> > > Would be great if you could do a start with OJB. Maybe others will
> > > chime in as soon as the initial pain of getting it started is
over.
> > >
> > > Oliver
> > >
> > >
> > >
> > > On Fri, 03 Dec 2004 11:15:28 +0900, Carlos Villegas
> <[EMAIL PROTECTED]> wrote:
> > > > Well I have experience with OJB but not the time :-(
> > > > I had promissed to look at the issues about the property-value
> field for
> > > > storing lists like the revisions or group members. Maybe I can
do
> it as
> > > > part of that but I'm still trying to make the time...
> > > > OJB will do just fine for Slide purposes and it's simple enough.
> The
> > > > Java code for OJB is very readable, more than the embedded SQL
in
> raw
> > > > JDBC which adds to the maintainability.
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > James Mason wrote:
> > > > > This is sort of on my todo list, but the only O/R tool I'm
> familiar with
> > > > > is Hibernate and for licensing reasons we can't integrate that
> with
> > > > > Slide (this may change in the future). I looked at OJB, but I
> wasn't
> > > > > impressed with some of the hoops I would have to jump through
to
> > > > > accomplish, for example, lazy instantiation.
> > > > >
> > > > > I think this is the right way to go, if someone with the time
> and
> > > > > knowledge is willing to chip in. Right now I don't really have
> > > > > either :).
> > > > >
> > > > > -James
> > > > >
> > > > > On Fri, 2004-12-03 at 09:18 +0900, Carlos Villegas wrote:
> > > > >
> > > > >>This is simple enough. But how about using one of the O/R
> mapping tools
> > > > >>like Hibernate, Apache's OJB or Torque. The table names or
> mappings are
> > > > >>usually setup in an external configuraton file. It adds
> additional
> > > > >>benefits like supporting more databases and keeping all the
> database
> > > > >>adapters in sync since they all become just one. Converting
JDBC
> code to
> > > > >>OJB, for example, is straightforward, we have done it,
specially
> if
> > > > >>there are no stored procedures like in Slide.
> > > > >>
> > > > >>Carlos
> > > > >>
> > > > >>Warwick Burrows wrote:
> > > > >>
> > > > >>>There's something about preprocessing Java source that makes
me
> a little
> > > > >>>uneasy :-) Isn't there another way? eg. instead of inserting
a
> placeholder
> > > > >>>that gets replaced simply change the jdbc operation strings
> passed to the
> > > > >>>jdbc client as in this example?
> > > > >>>
> > > > >>> "select name from " + Config.table_prefix + "PROPERTIES
> where
> > > > >>>field=1"
> > > > >>>
> > > > >>>Java will insert the prefix into the command automatically.
> There's no need
> > > > >>>for preprocessing and the amount of work required to change
the
> code to suit
> > > > >>>this approach is no more or less than that needed to insert a
> placeholder
> > > > >>>string?
> > > > >>>
> > > > >>>Warwick
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>-----Original Message-----
> > > > >>>>From: Richard Emberson [mailto:[EMAIL PROTECTED]
> > > > >>>>Sent: Thursday, December 02, 2004 3:51 PM
> > > > >>>>To: Slide Users Mailing List
> > > > >>>>Subject: developers: table prefix
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>This subject has been kicked around recently. Basically,
> > > > >>>>there is an easy way to do it but if none of the Slide
> > > > >>>>developers are interested then it will never go anywhere.
> > > > >>>>
> > > > >>>>How to add table prefixes to Slide's database table names -
> > > > >>>>the simple way:
> > > > >>>>
> > > > >>>>Alter the build.xml file so that it does a filtered copy to
a
> > > > >>>>new directory "build/gen_src" prior to compilation.
> > > > >>>> It is from this directory that the
> > > > >>>>sources are then compiled. Each table name in the source has
> > > > >>>>the string "@TABLE_PREFIX@" prepened to it. The
> > > > >>>>build.properties file has a new property:
> > > > >>>>
> > > > >>>>table.prefix=<value>
> > > > >>>>
> > > > >>>>The "value" can be, for example, empty resulting in the
> > > > >>>>current table names or one might set the value to "SLIDE_"
> > > > >>>>which would result in that string being prepended to all
table
> names.
> > > > >>>>
> > > > >>>>Additional benefits:
> > > > >>>>
> > > > >>>>One can now add properties to the build.properties file:
> > > > >>>>
> > > > >>>>version.major=2
> > > > >>>>version.minor=1
> > > > >>>>version.release=0
> > > > >>>>
> > > > >>>>which could be used during the filtered copy to embed the
> > > > >>>>Slide version number is some class which can be accessed at
> runtime.
> > > > >>>>
> > > > >>>>The build date, who built the code, compile host
> > > > >>>>architecture, java version and vender doing compilation, cvs
> > > > >>>>version tag, etc. can also be generated by ant and used
> > > > >>>>during the filtered copy to add more runtime accessible
> > > > >>>>information. For those embedding Slide in a J2EE
application,
> > > > >>>>this information would then be accessible via a JMX page.
> > > > >>>>
> > > > >>>>None of this is hard to do, its just a question of
> > > > >>>>identifying someone (with checkin ability) to take the first
> > > > >>>>step - altering the build process.
> > > > >>>>
> > > > >>>>Richard
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > 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]
