开发者

MVC - Should the View be allowed to interact directly with the Services without going through Controller

开发者 https://www.devze.com 2023-04-13 02:28 出处:网络
My architecture looks like this: View - Controller - Services Think of one of the views as a Person details page. The controller calls

My architecture looks like this:

View - Controller - Services

Think of one of the views as a Person details page. The controller calls

(Person) service.getPerson(1234)

and returns the Person instance to the view to display. The way the service fetches the Person is by interacting through a RESTFul webservice.

The restful service responds back with following response:

<person>
  <id>1234</id>
  <name>John Doe</name>
  <person-detail-uri>/person/1234/detail</person-detail-uri>
</person>

The above response is mapped to a class called Person that looks something like this:

class Person{
    Long id;
    String name;
    String age;
    String address
}

A complete person object can be created by getting the person throu开发者_运维技巧gh

/person/1234

and then the details through

/person/1234/detail

Assume that the view needs to display person details.

Question:

Option A: Should the Controller call getPerson() and getPersonDetails() on the service to create a complete Person instance

or

Option B: Just getPerson() and let the view call person.getAge() that will somehow(probably through aspects) trigger a details fetch.

I lose some flexibility in Option A, however, it makes the model very dumb which I consider a good thing because then a bad code in view cannot pollute caches and hence may not cause performance concerns.


There's no "should", it just depends. IMO it's risky to allow the view layer to do lazy initialization because it's easy to accidentally fire off lots of queries without meaning to.

In addition, it makes the view layer fairly intelligent in that it now controls data initialization rather than isolating data fetch in the controller or model. I like dumb views, but that may be bias, rather than something based on a purely technical argument.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号