1

When I reading some Java EE Projects, I found that these projects's structure,framework is complicated,maybe unnecessary,isn't?

Usercontroller 1 file

UserService,UserServiceImpl 2 files

UserDao,UserDaoImpl 2 files

my job just simple,just CRUD, when I change something, I have to edit unless 4 files,poor efficiency,isn't? does thoese layer setting change effect of performance ?

Usercontroller - UserService extend BaseService - BaseDao does these more simple and more effective，or more productive ？

if you have 2 job, internet web project and enterprise mis

can you tell me what is your opinion about layer structure?

skaffman
  • 398,947
  • 96
  • 818
  • 769
achan2090-user1319768
  • 13
  • 3
  • 1
    http://stackoverflow.com/questions/8993318/what-is-the-right-way-to-use-spring-mvc-with-hibernate-in-dao-sevice-layer-arch – Ramesh Kotha Apr 08 '12 at 03:36

2 Answers2

3

There is nothing preventing you from querying the database directly in your controller. However one day you realize that:

  • You would like to share your business logic with web-services. Suddenly you realize all the business logic is inside your controllers. You have to extract it into separate classes (called a service layer) and reuse that code from both controller and web service

  • The other day someone decided to switch from to . Suddenly you find native database SQL queries all over the place (no longer in controllers, but in services). For the sake of maintainability you decide to move all database related code to separate classes (called a persistence layer or DAO layer)

  • After migrating to Oracle database once again you were asked to switch to this time. But instead of rewriting existing UserDao you change it to interface, leave original implementation in OracleUserDao and create a second implementation called MongoDbUserDao

  • During unit testing you have discovered that mocking service classes is cumbersome. Also it is hard to see business methods in a class, so you extract a service interface with well-defined API

Guess what, nobody forces you to follow 3-tier architecture - but it emerges naturally during development. You can either wait for it or start with if from day one.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
0

Taking out the interfaces you're tightly coupling your layer implementations, which will be problematic once you want to mock something and use that mock in tests. You DO have test suite, don't you?

Apart from that, programming vs. interface lets you change the implementation whenever you want. So without changing the code from other layers you can for example connect to remote service layer instead of a local one.

soulcheck
  • 36,297
  • 6
  • 91
  • 90