Where does Business Logic belong
andre...@bellsouth.net
I have encountered a recurring issue at various clients and wanted
the input of the MJUG community. The question is simple. (If only
the answer were simple also) Where should business logic reside? In
application code? In application code but implemented through an
external rules engine? In Stored Procedures? I found some initial
discussions on this topic.
http://c2.com/cgi/wiki?BusinessLogicInStoredProcedures
http://thinkoracle.blogspot.com/2006/01/plsql-vs-j2ee.html
Let me know what you think
Andres Anon
Borislav Iordanov
The most important thing is to beware of dogmatic views of the right
or wrong way ;) This a general question about a technological choice
and the answer is very much context dependent. I just want to point
out an aspect that's frequently ignored: the organizational aspect. If
you work at an organization with a very strong stored procs tradition,
lots of oracle expertise, you are providing them good service by
leveraging that expertise. If, on the other hand, the Java team is
larger and stronger and DBAs always make it difficult to roll out
changes ;), then work with Java. And if you work in an organization
where you don't have many hard-core developers, but rather many
tech-savvy domain experts, then a rules engine could be put to use.
Also, I don't think that there should be absolute consistency across
the board by mandating that ALL business logic should be here or
there. There's always a price to pay for that consistency since you'd
be trying to squeeze every single problem into a single technological
prism.
Best,
Boris
Chris Bredesen
> The most important thing is to beware of dogmatic views of the right
> or wrong way ;) This a general question about a technological choice
+1
> and the answer is very much context dependent. I just want to point
> out an aspect that's frequently ignored: the organizational aspect. If
This is what I was about to respond with, but Boris has nailed it. If
you're in a Java shop, don't let your Oracle DBA convince you that you
MUST WRITE PROCS OR ELSE RAAAWWWRRRRRR!!!!! ORM solutions and design
patterns allow us to solve business problems in well-known ways.
If you're a JSP guy in a shop of Oracle developers, then maybe letting
them solve the business logic is a good thing. But if you do this, you
can throw out your rich domain model and unit tests and pretty much
everything we as Java developers find comforting.
> you work at an organization with a very strong stored procs tradition,
> lots of oracle expertise, you are providing them good service by
> leveraging that expertise. If, on the other hand, the Java team is
> larger and stronger and DBAs always make it difficult to roll out
> changes ;), then work with Java. And if you work in an organization
> where you don't have many hard-core developers, but rather many
> tech-savvy domain experts, then a rules engine could be put to use.
A declarative, rule-based approach to things is a tool for a certain
kind of job. The right job for this tool is now becoming clearer and
truthfully, there are not a lot of people who know how to identify it.
Same with workflow/bpel stuff. Are you matching stuff against hundreds
or thousands of rules which change rapidly? Maybe drools is a good
thing for you. Rules engines aren't going away, that's for sure. But
this is a tool I'd use with extreme caution and with the supervision of
someone who knows the lay of that land.
> Also, I don't think that there should be absolute consistency across
> the board by mandating that ALL business logic should be here or
Again, right tool for the job. I'm a Java guy, but there are times when
a SP solves the problem right, and you can avoid the "who did the work?"
problem with good javadocs.
> there. There's always a price to pay for that consistency since you'd
> be trying to squeeze every single problem into a single technological
> prism.
If you are going the Java route, be sure to understand your domain model
and what services you're going to provide. Think about transactions and
unit testing and invocation points. Read PoEAA by Fowler. He lays it
all out straight. I used to be an anemic domain model guy, but I broke
myself of that once I realized it was OK to have a rich domain model and
not bake persistence into it (read Get Hibernate out of my POJO's by
Barroso, hehe).
>
> Best,
> Boris
Cheers,
Chris (no longer in Miami)
Michael Feathers
I agree. There is much that is context-specific, particularly wrt
staffing. My preference, though, is to look at stored procedures as an
optimization. They just don't refactor and test as easily as code.
Michael