CODEWITHSUNDEEP
javainterfaceejb
WelcomeTo
WelcomeTo

Reputation: 20581

Using EJB interface for helper class

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?

Upvotes: 0

Views: 1037

Answers (2)

Gonzalo Garcia Lasurtegui
Gonzalo Garcia Lasurtegui

Reputation: 4941

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.

Upvotes: 1

techuser soma
techuser soma

Reputation: 4877

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.

Upvotes: 1

Related Questions