This week's book giveaway is in the General Computing forum.
We're giving away four copies of Learning Regular Expressions and have Ben Forta on-line!
See this thread for details.
Win a copy of Learning Regular Expressions this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

All business logic in EJBs  RSS feed

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
In your experience with building real-world J2EE-based applications, do you find it practical (or possible to say the least) to place all business logic in EJBs? I find it difficult to imagine an application that completely adheres to this "best practice". There must be some business logic somewhere in the web client that controls the business logic or at least decide which business logic to invoke. Any thoughts?
 
Bartender
Posts: 19734
92
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am a VERY firm believer in consistency, but I HATE dogmatism. EJB's have enough overhead, that I don't recommend using them as a "one-size-fits-all" solution. On the other hand, if you're looking to make a point-reference implementation of business logic that will be referenced by multiple servers, an EJB might be the best solution, It depends. I know some places who use DBMS stored procedures as for the same general reason.
 
Author
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Tim. For some deployments, putting the logic in EJBs is better than stored procedures, for others the reverse is true. It really depends on a lot of things: (a) to what extent your app is database driven, (b) whether or not stored procs are expressive enough to capture your business logic requirements, (c) integration with third party systems, (d) level programmer competence with EJB or stored procs, and there are other issues.
As a general rule, my belief is that - for performance reasons - if your app is heavily database driven (and especially if the data is highly dynamic), you should push your logic as close to the database as you can get it (i.e., stored procs). Reason being: unless you want to spend your time tweaking an application-level cache, working with data in the database efficiently means working within the address space of the database system software. Databases like Oracle, that are ported to the major OSes, are portable, so as long as your database runs on a given OS, so does the stored procedure. Also, the database folks have spent a lot of time ensuring that the common case use of something like PL/SQL generally interacts fast with the data.
On the other hand, if your data is not too dynamic or you do not own the database you integrate with, etc. you might want to use EJBs. They give you better deployment options because they are at a higher level of abstraction. They give you more flexibility in deployment, more modeling options, and potentially more expressivity.
I think there are many folks out there using Session EJBs and stored procs (no entity beans). I'm not sure how long that trend will continue or whether it splits the difference in the two approaches. I think it's not a bad idea, but again it depends on the deployment.
Hope that helps.
 
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A lot of this argument comes down to the definition of the term "Business Logic". This can encompass many different parts of an application. In general, I find it easier to consider Servlets to be controllers, which manage application flow, which could be viewed as a kind of business logic, but to put my domain-specific business logic (like order management) inside the EJB's. However, as others have pointed out, each project is different and different conditions may apply.
A really good reference for understanding the kind of layering decisions that go into this kind of architecture is Martin Fowler's Enterprise Architecture Patterns which covers this in depth.
Kyle
 
Eric Lim
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for all the input.
"Enterprise Architecture Patterns" looks pretty good at first glance.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!