0

My colleague told me that EJB itself shoudln't contain any method implemetation, it must only delegate method calls to some "helper" classes, i.e. EJB methods should look like this:

public String bsuinessMethod1() {
   return helper.bsuinessMethod1()
}

public void bsuinessMethod2() {
   helper.bsuinessMethod2()
}

And the reason to delegate methods like above, is to have less coupled code (for example when I want to reuse methods of "helper" class not in EJB context). Also he told that business methods shouldn't know anything about Java EE.

(Correct me if above statement is wrong, and please note that we don't use JPA transactions, we use another framework to dealing with data persistence)

So if above statement is correct, my "helper" classes should have the same methods as EJB. So can I reuse EJB interface for helper class (i.e. make helper class to implement same interface as EJB)? Would not it be bad from an architectural point of view?

techuser soma
  • 4,766
  • 5
  • 23
  • 43
WelcomeTo
  • 19,843
  • 53
  • 170
  • 286

2 Answers2

1

My colleague told me that EJB itself shoudln't contain any method implemetation, it must only delegate method calls to some "helper" classes

I don't think you get much benefit from it. Why not placing the business logic directly in your EJB? I don't see any downsides honestly.

And the reason to delegate methods like above, is to have less coupled code (for example when I want to reuse methods of "helper" class not in EJB context)

You can still have decoupled classes and use your EJBs for more than just delegating to a helper class. Decoupling depends more on program to interfaces and using dependency injection than on delegating to helper classes.

Also he told that business methods shouldn't know anything about Java EE.

If you annotate your business classes (EJBs) with @Stateless (which is part of Java EE) they won't be Java EE agnostic anymore.

So if above statement is correct, my "helper" classes should have the same methods as EJB. So can I reuse EJB interface for helper class (i.e. make helper class to implement same interface as EJB)? Would not it be bad from an architectural point of view?

This doesn't make sense from a design perspective, and goes back to the point of having dummy EJBs that simply call helper classes.

Community
  • 1
  • 1
Gonzalo Garcia Lasurtegui
  • 4,911
  • 5
  • 32
  • 49
  • ok, thanks. But what about testing? Having `helepr` class I easy can test him, but when all logic concentrated in EJB I can't test it without deploying – WelcomeTo Mar 02 '13 at 10:47
  • Also I don't clearly understand your comment about `@Stateless` (`they won't be Java EE agnostic anymore`). My helper classes not annotated with `@EJB`. They are simple POJOs. And they easy can be reused, for example, in applet. But I can't create new EJB bean in applet – WelcomeTo Mar 02 '13 at 10:50
  • Having a "helper" class only doesn't make your EJB more testable. Actually, why would you test your EJB if it doesn't contain any logic? What are you testing then? What makes it more testable is programming your "helper" class to an interface, so that you can use a mocking framework like EasyMock or Mockito to mock it. I don't think I understand your second comment. – Gonzalo Garcia Lasurtegui Mar 02 '13 at 17:37
1

I dont think

delegate method calls to some "helper" classes

, means keep the ejb method one liner that just calls the helper class(es). The intent of delegating the implementation to an helper class is to use the core computation by different kinds of service exposers (ejb, pojo, web service etc). This also helps to easily port the service from an ejb to a non ejb.

Having the computation in helper classes would help to expose the services in multiple ways if required. All of them can use these helper classes for the core computation.

Say, we need a service to retrieve the average temperature of a day for a given city. Pardon if the example does not look good but i hope it expresses the idea. The service needs to

  1. Retrieve the list of temperatures from the db for the given city for the day. (In DB they are stored as 40 F, 5 C etc).
  2. Parse the temperatures to identify the unit of measurement and convert to Fahrenheit.
  3. Filter invalid temperatues (zeroes and values containing invalid characters etc).
  4. Calculate the average.

In this scenario items 2, 3 and 4 makes sense to be moved to an helper class. Item 1 is not recommended to be part of an helper class.

Now this helper class can be used by a) A pojo service. b) An ejb. c) A web service or others.

techuser soma
  • 4,766
  • 5
  • 23
  • 43
  • Thanks. But why item 1 is not recommended to be part of an helper class? Because database-specific operations must reside in DAO classes? Or what you mean? – WelcomeTo Mar 02 '13 at 10:57
  • @MyTitle yes, so helper class is not afffected by transaction boundaries, making it more reusable. – techuser soma Mar 03 '13 at 06:33