Difference between teams, form, business and entity objects in terms of Spring?

Question

I try to bow my head to the differences between these objects in terms of loosely coupled systems. Is the business object the same as the object of the object? Can I use a business object or an object object in MVC as an object of my team? Is the command object the same as the form object? Just look for explanations of object types in terms of Spring and usage.

I found some questions about stackoverflow, but nothing that explained it to my liking.

Spring Web MVC Docs seem to say that you can use your business objects (entities?) As objects of your team / form, but doesn't that contradict the separation of concerns?

From Spring Docs:

Reusable business code, without the need for duplication. Use existing business objects as objects of commands or forms instead of mirroring them to extend a specific base class of the database.

Answer 1

1) Technically, business objects and business objects (or “entity objects,” as you call them) do not match.

Business entities contain data. While business objects contain logic for your business objects (how you create your entity, how to update it, etc.). Business objects are technically an old J2EE template, I have not seen it in current codes, so I cannot go into details. Some people will say that the business objects correspond to the DAO, while others prefer to say Services. And some developers simply say that business objects and objects are the same, because they believe that the “object” and “entity” have the same level of detail, either because their business entities also contain logic, or simply because they don’t know. I simply prefer to talk about “business entities” for objects containing data, and I never use the term “business entity” because it can have different interpretations.

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

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

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

Reusable business code, without the need for duplication. Use existing business objects as commands or form objects instead of mirroring them . specific base database class.

So you can - and you should, according to Spring - use the business object as your command / form object. If you're not sure, here are a few reasons:

• For simplicity. And God knows that our Java software architectures need more simplicity. Some companies use too many layers to do very simple things. Many initiatives have been taken to combat this, led by Spring, Java (see below), and more.
• For himself, because he simplifies, simplifies and mixes programming
• Because Spring and Java (via JSR) talk about this. Indeed: what do we expect from a form object? Formation and probably some validation. How will we do this check? Spring MVC 3 supports @Controller input validation with JSR-303 @Valid annotation. Where will we set limits for verification? According to JSR-303, the best place to store these restrictions (@NotNull, @Length, etc.) is located inside the business object itself. Bottom line: it is better to use the business object as your command / form object.
• Separation of issues is still respected. This is only one concern (form support) is no longer a concern! Spring MVC handles it for you. :-) You just need to worry about your entities.