7

I'm trying to wrap my head around the differences between these objects in terms of loosely coupled systems. Is a business object the same as an entity object? Can I use a business or entity object in MVC as my command object? Is command object the same as a form object? Just looking for a clarification of the types of objects in Spring terms and usage.

I found a few questions on stackoverflow, but nothing that explained it to my liking.

Spring Web MVC docs seem to say you can use your business (entity?) objects as your command/form objects, but wouldn't this go against separation of concerns?

From the Spring Docs:

Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them to extend a particular framework base class.

Jerome Dalbert
  • 10,067
  • 6
  • 56
  • 64
acvcu
  • 2,476
  • 10
  • 40
  • 56

1 Answers1

11

1) Technically, business objects and business entities (or "entity objects" as you call them) are not the same.

Business entities contain the data. Whereas business objects contain the logic about your business entities (how you create your entity, how you update it, etc.). Business objects are technically an old J2EE pattern, I haven't really seen it in current codes so I cannot go into specifics. Some people would say that business objects correspond to DAOs, others would rather say Services. And some developers just say that business objects and entities are the same because they think that "object" and "entity" have the same granularity, or because their business entities also contain logic, or just because they don't know. I just prefer to talk about "(business) entities" for objects containing the data, and I never use the term "business object" because it can have different interpretations.

2) According to Spring MVC documentation, a command object is a JavaBean which will be populated with the data from your forms. On the other hand, what is a form object, but an object backing your form ?

So yes, a command object is semantically the same as a form object. I prefer the term form object, that I find immediately understandable.

3) As you said, according to Spring MVC documentation, one feature of the framework is

Reusable business code, no need for duplication. Use existing business objects as command or form objects instead of mirroring them to extend a particular framework base class.

So yes, you can -and you should, according to Spring- use a business entity as your command/form object. If you are not convinced, here are some reasons :

  • For the sake of simplicity. And god knows that our Java software architectures need more simplicity. Some companies use way too much layers to do very simple stuff. Lots of initiatives are done to counter this, led by Spring, Java (see below) and whatnot.
  • For your own sake, because it makes programming simpler, easier and funnier
  • Because Spring and Java (through JSRs) say it. Indeed : what do we expect from a form object ? Form backing and probably some validation. How would we do this validation ? Spring MVC 3 supports the validation of @Controller inputs with the JSR-303 @Valid annotation. Where would we put the constraints to validate ? According to JSR-303, the best place to store these constraints (@NotNull, @Length etc.) is within the business entity itself. Bottom line: it is better to use a business entity as your command/form object.
  • The separation of concerns is still respected. It's just that one concern (form backing) is not a concern any more ! Spring MVC handles it for you. :-) You just have to worry about your business entities.
Jerome Dalbert
  • 10,067
  • 6
  • 56
  • 64
  • 2
    So the business entities are associated with the Presentation and DAO layers? I understand how that makes them reusable, but you still somewhat mix DAO-related annotations ('@Entity') with the Presentation layer. It sounds like this isn't an issue though - maybe I'm trying to be too strict about separation of concerns. I have my Presentation layer packaged in a WAR, and the Service/DAO layers in a separate project in a JAR file. If I wanted to somehow swap out my Service/DAO layer, wouldn't this break my form objects? – acvcu Jul 16 '12 at 13:19
  • 2
    @acvcu If data in your form and data in your entity are roughly the same, just use the entity as your form object. Now an architecture is just all about context and is flexible. If you really think your service/dao layer can wreak havoc, feel free to have separate form object/DTOs and business entities. You will have a more secured presentation layer, at some cost though (complexity + coding time). Another good reason to have separate from objects/DTOs would be legacy systems, where existing entities can have too much fields or useless fields, but you want your new UI to be clean and simple – Jerome Dalbert Sep 15 '12 at 17:14
  • @JeromeDalbert If I use same object for DAO and form, will it not cause problems where i am using hibernate which automatically tracks changes in the business entities. For example if one of my form updates User entity but it updates only two attributes. Now when my hibernate transaction starts at Service layer where the form object containing only these objects are populated it will break the code as other attributes are not being populated by form. Or should I retrieve a new object in service layer and copy everything from form object into this new object or something like that? – Shailesh Vaishampayan May 27 '14 at 15:01