1

I wants to develop service layer for my application using java. At the same time the service layer can also be exposed to webservice also.

My idea is to create one Generic Abstract Class for database operations , and all other service classes extend that abstract class and do the DB operation through that abstract class methods.

Is this a good idea to do it? Please help me

Dilip
  • 929
  • 3
  • 13
  • 32

2 Answers2

5

It's hard to say with so few details, and without even knowing what you'll use to access the database (JDBC? JPA? Hibernate?). But

  • the service layer and the persistence layer are not the same thing. To ease decoupling and testability, I prefer having a pure service layer and a data access layer
  • inheritance is generally not the best way to reuse code. Use a well-design API, and prefer delegation over inheritance.

Also, don't reinvent the wheel. EJB3, Spring and other frameworks have good support to develop services and expose them as web services.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Thank you for your prompt reply. – Dilip Jan 06 '12 at 08:09
  • I am using hibernate and spring , as per my team decision they dont want to have the separate service layer , use DAO layer in the controller directly and do the DB operations. For that DAO layer we are going to use the Facade Design pattern like what i said in my question.After that we are going to expose each DAO class method as a webserivce. It is good to do that? Please help me. Thanks in advance. – Dilip Jan 08 '12 at 11:48
  • No, it's not a good idea. An atomic transaction usually spans multiple DAO calls (example: debit an account and credit another one). So you need to always go through a facade layer (or service layer: it's another name for the same thing) to demarcate transactions. – JB Nizet Jan 08 '12 at 15:33
  • So what you are saying is create separate layer for webservices? – Dilip Jan 08 '12 at 15:50
  • Yes, and also for services called from the controller. The controllers shouldn't have to demarcate transactions. – JB Nizet Jan 08 '12 at 15:55
  • Thank you so much for your kind reply. i am not understanding what you mean by "The controllers shouldn't have to demarcate transactions" Can you please explain more...? you are saying we can't use the DAO class object directly in controller ? If yes please explain me why.. Thank you – Dilip Jan 08 '12 at 16:32
  • Because you need a transaction to call DAOs, and you need to include multiple DAO calls in the same transaction (else, you might credit an account without debitting the other one, for example). So, you need to start a transaction, call multiple DAOs, then commit the transaction, or rollback it if an exception occurred. That's not the responsibility of the controller layer. It's the responsibility of the service layer. EJBs, and Spring services, allow defining services which are automatically enclosed into a transaction. – JB Nizet Jan 08 '12 at 16:36
  • Thanks again. What i understand from your word is service layer will be called by controller and service layer will call the multiple DAO's , at the same time service layer will take care of the transaction management . Please correct me if i am wrong.... – Dilip Jan 08 '12 at 16:44
  • You got it. That's what I meant. – JB Nizet Jan 08 '12 at 16:52
  • +1 "a pure service layer": I have asked "what use are EJBs" http://stackoverflow.com/questions/5579890/what-use-are-ejbs. The answer I accepted was that they can be used to create the service layer. – Raedwald Mar 10 '12 at 17:25
1

You should consider using some framework, which will help you with routine. E.g. Spring or Java EE. Those frameworks can offer you many built-in solutions like IoC, declarative transactions, declarative security etc.

Artem
  • 4,347
  • 2
  • 22
  • 22