Difference between Spring Service and Controller

[Eric B]

Hi,

I'm having trouble understanding something in spring and how it relates to Granite, and am hoping that someone could help clarify things for me.  To be honest, I'm not 100% up to speed with Spring terminology, and probably the root of my problem starts there - I'm usually a Struts2 MVC guy.  I'm having trouble understanding the difference between a Spring Controller and a Spring Service, and how a Flex component communicates with them. 

I've seen two examples (both working) - one that uses a Spring Service to communicate with the Flex component and one that uses a Contoller with a RequestMapping (ex: @RequestMapping( "/test/somePath").  When I dug into the AS3 files generated by the flex mojo plugins, I didn't see any reference to the complete path for the RequestMapping (ie: "test" doesn't seem to exist anywhere), and yet if I change the path, I run into trouble.

Can anyone help me understand the difference between a Service and Controller as far as it is required by Granite, and what the recommended communication method is?

Thanks!

Eric

[anand sharma]

i think conceptually they both are on the same pitch but working with controller is more easy and promotes tight coupling it is best place for handling session related stuff where as service promotes lose coupling and high encapsulation but a bit harder to implement.

[mxa]

Hi,
so in Spring the Controller is afaik similar to the Action in Struts.
The Methods that are called at the Controller annotated class with the
RequestMapping annotations usually return a ModelMap that contains the
data which is usually then rendered by the jsp/jstl files.

If I remember it correctly from the Flex/GraniteDS site you call
[In]
public var fooController:Component;
......
fooController.bar();
.....

if you have on the Spring site a controller like this:

@Controller
public class FooController{

@RequestMapping("/foo/bar")
public ModelMap foo(){
ModelMap mm = new ModelMap();
//...fill mm....
return mm;
}

}
(I think the "Foo"Controller name forces the /"foo"/.... mapping, but
not sure on that anymore)

The Service annotated classes in Spring represent the buisness logic
components and since you don't want to actually think about a "web mvc
requestmapping" layer between your granite/flex client and your
backend, I think the Service classes are the more desired approach.
So you define a class
@Serivce
public class FooService {

public void doLogicStuff(){

}
public void createBar(Bar b){

}

}
Another advantage of that is that the GraniteDS builder plugin for
eclipse generates you as3 proxies for these services, that make
programming just more enjoyable :)

so than you can do stuff like that on the granite/flex site:

[Inject]
public var fooService:FooService;
....
fooService.doLogicStuff();
.....or
var b = new Bar();
fooService.createBar(b);
.....

I think the only reason why you may use controllers is, if you want to
take advantage of Granite's PagedQuery Class.

HIH
max

[wdrai]

The support for Spring MVC controllers has been implemented mostly to support Grails controllers and be able to benefit from Grails scaffolding.

Honestly with plain Spring, since we added the new typesafe AS3 proxies, I would strongly advise to simply use services. I think that controllers in Spring MVC are not very readable, and the only advantage they provide with GraniteDS is the automatic binding of the returned model variables in the context. It can save a few lines of Flex code, but I don't think it's really worthy. Unfortunately the Spring examples still use controllers but we'll change that in GraniteDS 3.

[Eric B]

On Thu, May 5, 2011 at 6:14 PM, wdrai <willia...@gmail.com> wrote:

 

Honestly with plain Spring, since we added the new typesafe AS3 proxies, I would strongly advise to simply use services. I think that controllers in Spring MVC are not very readable, and the only advantage they provide with GraniteDS is the automatic binding of the returned model variables in the context. It can save a few lines of Flex code, but I don't think it's really worthy. 

Thanks for the info/tip.  But can you please elaborate by what you mean with "automatic binding of the return model variables in the context"?  I'm not quite sure what you are referring to.

Thanks!

Eric

 

[wdrai]

Methods of a Spring MVC controller should return a ModelMap object. Values of the map are bound in the Tide context, so for example you can do something like this :

Spring controller :

public ModelMap list() {

    return new ModelMap("someList", new ArrayList());

}

private function refreshList() {

    someController.list();  => The variable someList of the model map will be merged with the variable someList in the context

}

[In] [Bindable]

public var someList:ArrayCollection = new ArrayCollection();

<mx:DataGrid dataProvider="{someList}"/>

<mx:Button label="Refresh" click="refreshList()"/>

[Eric B]

Hi,

So I'm running into some push back from colleagues relating to how to implement Flex in an MVC model.

From what I've read online, as well as your insights, it would seem that the preferred method to integrate a Flex client with an app is through a Spring Service and not a controller.  But that would essentially bypass the "C" part of MVC.

Considering that the Flex component is essentially a "View" replacing the typical HTML view in the MVC model, what is the rationale for completely bypassing the "C" part of the MVC model in this case?

The way I see it, one can still use a service as the "C" part, although it is not technically defined as a "C".  Additionally, I see the Spring Controller as mapping more specifically towards http requests/responses (ie: request params, response headers, etc), which you don't really get with the Flex integration given that all communication is over the gravity servlet.  However, that being said, the communication is technically still happening over Http request/response pairs though serialized information.

Does anyone have good arguments that I can use to sell the benefits of using Services rather than Controllers?

Apart from the lack of separation of code (ie: no more "C" layer between the "V" and the Business Logic), the app is going to have some HTML view components to it as well.  So consequently, we will end up with a Controller for the HTML view, but no controller for the Flex view, which can potentially be confusing.

Having tried to build a sample example with a Spring Controller and a Spring Service, I much prefer the tighter coupling and syntax checking with the Service.  That being said, it goes against the concept of loosely coupled layers.

Any insights or suggestions would be greatly appreciated!

Thanks,

Eric

[wdrai]

In a classic RIA architecture, the Flex app itself contains all the MVC layers, and client controllers call server-side services.

There are other possible architectures, but this is the most common.

[Eric B]

On Tue, May 10, 2011 at 4:56 AM, wdrai <willia...@gmail.com> wrote:

In a classic RIA architecture, the Flex app itself contains all the MVC layers, and client controllers call server-side services.

There are other possible architectures, but this is the most common.

Very interesting.  I had not realized that at all.  Thanks for the clarification.

Eric