2009/6/9 Richard Hauswald <richard.hausw...@googlemail.com>:
> I'm not sure if I got this right, but it seems that many of you say,
> that transactional services means using DTO's. I'm using transactional
> services without DTO's most of the time. I only use DTO's if the
> structure of the domain model doesn't allow transferring it, eg if its
> too complex or a large byte[] would be loaded but never shown to the
> user. I really try to avoid the use of DTO's wherever possible - 95%
> at a guess.
You mean you always return objects that are completely initialized,
i.e. all lazy collections required have been populated before the
instance is returned to the UI tier ?
This means that you have different service methods to return objects
that require different init states etc doesn't it ?
This eventually means that you have to write DAOs and HQL and stuff,
that match the exact functionality of each use case...
Last, it actually makes you objects simple DTOs. Ok, you share a
common class for "real" objects and detached ones, but then there are
some methods that you can't invoke any more on the object (if it's not
correctly initialized)...
To be honest, I have practically no Services either in most of the
apps I write. The domain objects simply encapsulate the logic of
the... domain :P
In the end, most of my apps en up by loading an initial object in some
way, using the hb session, and then invoke methods on this object
and/or some of its collaborators. Those methods can be invoked without
even caring about transactions at all. And code isn't cluttered with
stuff like :
class MyService {
public MyClass loadForFunctionalityOne(..) { ... }
public MyClass loadForFunctionalityTwo(..) { ... }
}
not mentionning the burden for the caller...
> IMHO a rule engine for transaction declaration at filter level leads
> to the need for rule set maintenance.
Exactly. It's a separate concern : you have folks that write the rules
that ensure there's no fraud on your website. That's what many big
vendors do with JRules, really. They look at the logs and usage of the
website and write the appropriate policies. Developers of the actual
web front end don't even know about it.
> Using annotated service methods
> there is no need to maintain a filter set since the configuration is
> located at the method and can not exist without it.
Again, it's another concern IMO. The fact that the tx spans over the
whole request or over a single method call isn't relevant there.
OSIV might be more resource consuming on the db (only profiling can
tell, it depends on the db vendor etc), but it proposes a much, much
simpler programming model when it comes to lazy loading etc. It really
allows to use your persisted objects transparently, which I've seen as
a big advantage in ORMs from their early beginning. I dream of the day
when OODBs will be popular and you'll be able to deploy solutions
using them at large vendors / hosting solutions... and we'll never say
"SQL" ever :)
> I think caching is kewl for data retrieval apps but it gets complex if
> you have to work on data which is likely to change very often.
Caching is mandatory if you wanna scale with any webapp. Even serving
images can be resource consuming, no need for databases. The cool
thing with hibernate is that 2nd level caching is quite easy to set up
and use.
But sure, it's application specific stuff.
> I'd suggest you to try the interceptor based approach in a little
> sample project to get a impression how much extra work it means for
> you and then decide yourself. I can provide you with a small kick
> start sample if you're interested.
That's probably the best option : try it out and figure out by
yourself. And tell us your feelings...
Cheers
Remi
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
