0

Environment :

Spring 4

Hibernate 4

MySQL

Spring MVC REST

Issue :

I am writing a simple REST based application for CRUD operations.

The architecture/components is below :

enter image description here

I have below design issues :

1. In Spring Application , the best practice is to have two separate contexts -

i) applicationContext : initialised through ContextLoaderListener (for servives abd daoLayerClasses)

ii) webApplicationContext : initialised through Dispather servlet (for Controllers/view Resolvers)

2. However I haven't seen any sample Spring REST based application using BOTH THE CONTEXTS above. Only Dispatcher servlet appraoch is used.

3. So , will creating two separate contexts for REST based application as shown in above architecture be an overkill and unnecessary ?

Or It is better to create two contexts separating SPRING REST layer in WebApplicationContext (@RestController) and ApplicationContext containing (@Services,@Repository)

tharindu_DG
  • 8,900
  • 6
  • 52
  • 64
Atul
  • 1,560
  • 5
  • 30
  • 75
  • This might also help explain why 2 contexts are used: http://stackoverflow.com/questions/18682486/why-does-spring-mvc-need-at-least-two-contexts – John Scattergood Dec 20 '15 at 07:49

2 Answers2

1

I think it is totally unnecessary to create separate contexts for your Controllers and Service/Repository classes unless you were thinking of having multiple Dispatchers or something like that. Generally you should keep it simple and have as few contexts as possible.

Dave L.
  • 9,595
  • 7
  • 43
  • 69
0

The answers to this question will be subjective, but as mentioned in other threads and in the Spring MVC docs two contexts are typical, but not the only way to do it.

I think the main reason is to separate them is when you have UI and APIs. They may depend on the same backend services, but probably shouldn't have co-mingled beans.

John Scattergood
  • 1,032
  • 8
  • 15