Announcement Announcement Module
Collapse
No announcement yet.
Any official "Goals of Spring Mvc" doc? Pojo's, etc? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Any official "Goals of Spring Mvc" doc? Pojo's, etc?

    Historically at my job, we've had 2 copies of the same data - a business object and a "view" object.

    We just switched from Struts to Spring MVC, and we've stuck with this model. I would prefer to go to having just 1 object that represents the data, and using that for everything.

    There's a guy on our team claiming we should actually have 3 different objects for the same data. He's claiming it's "good design" to do it that way, I'm saying it's bad design and one of the goals of spring was to be able to use the same pojo (plain old java object) for both data coming from the database layer, and also data in the view layer, without doing copying from one to another.

    Are there any official docs saying "these were the goals of the spring project"? It's been my understanding that getting rid of the struts ActionForm object and using the pojo directly was one of the specific goals of the Spring MVC Project, but all I can find is vague mentions of it, like here -
    http://www.springsource.org/features

    Modularity - Plain old Java Objects keep your code concise, simple and modula

    Would be extremely helpful to be able to point to an official page with a bit longer of an explanation...

  • #2
    There are tons of threads and discussions about that question... Both have pros and cons (although 3 objects seem a little overkill).

    I tend more and more to the CQRS and DDD models in which you have different classes for different domains (each problem domain has its own model). In CQRS they even seperate the read-only and write part of the model ... In general the model you need for displaying the data and working with it in the view layer is a different model you use in your backend. When using the same model for both backend en frontend you end up with some workarounds in your controllers or pages to get or view data.

    If your view and backend models don't really differ and you can use them without to much hassle use a single model.

    Comment


    • #3
      Originally posted by Marten Deinum View Post
      There are tons of threads and discussions about that question... Both have pros and cons (although 3 objects seem a little overkill).
      Any suggestions on tracking down some of those threads? keywords I might search for, etc? I did a search, and I'd love to read them but I'm having trouble tracking them down.

      Comment

      Working...
      X