Printable View
Which is the better approach?
1.) have the command object be operated on inside the controller via onSubmit
2.) Have the command object be operated on by some private method in the controller (separated out)
3.) Have a interface that operates on the command object.
Example: BlogService
would have createBlog(BlogCommand);
What are the advantagaes and disadvantage of each.
Always clearly separate the tiers and concerns. Your command objects and controllers live in the same tier and are specific to the same web application. Therefore, it is ok and appropriate for your controller to be aware of the command object. That's how Spring MVC works. So, your command object is passed to the controller upon the submission of the view. The task of the controller now is to convert the data from the received command object into a domain-specific object (not presentation-tier-specific) and pass it on to the middle-tier service (again, a non-presentation-tier-specific POJO) that performs the business operation on that data (i.e implements a specific use case.) Therefore, the only correct way to do it is to inject the reference to your business service POJO into your controller, and have the controller redirect the call to it. Never pass Command objects to a business service! Command objects themselves, however, may nest generic business domain objects, but not the other way around.
To summarize:
1. The view submits the populated Command object;
2. The controller converts that app-specific Presentation Tier object into a generic domain object that is recognized by the business service.
3. The controller invokes the appropriate method on the stored instance of the business service to perform the business operation. You must inject that business service reference into the controller when it is instantiated.
4. The Controller interprets the result of that business operation according to the application-specific requirements, and redirects to the appropriate view.
Regarding using private methods... Certainly, in most cases you should be abstracting any functional steps that implement a distinct operation in a separate private method. Subroutines were the first and the best form of abstraction introduced by Fortran (there was such programming language :) ), and using them is key to elegant, comprehensive, and maintainable software. The short answer, yes, use private methods to abstract any distinct functional steps in your code. Not only it will make it reusable, but even if you don't need to reuse it, it will make your code better structured, more modular, and more readable. Long methods suck. Always. ;)
HTH,
Constantine
Thank you.
how about in terms of webflow (for Action).
I mean i like to call like createBlogs(BlogCommand blogCommand) so I definitely don't like option 1.) in that case.
In the case of SWF, you will inject your service POJO into the ActionForm implementation for your view state (or Action if you are invoking the service call from an action state vs. view state transition.) What do you mean by option 1 not being acceptable? Action form is part of your C in the MVC, so passing your Command object to the controller is exactly what you need to do. Now, as I have told you, you must NOT - never - pass your command object to your business service. That means createBlogs(BlogCommand blogCommand) is just wrong. Assuming that you have some "BlogService" [service, middle-tier] class with a "createBlogs()" method, you need also to have some generic Blog-domain specific entity class, like Blog that would store the blog attributes. You read the user input (from the command object that may, in turn contain nested Blog objects, e.g. a List of blog objects) and pass the list of blogs into your service. It may be something as simple as:Quote:
Originally Posted by cablepuff
Code in your FormAction:
Hope this is clear. Again, note that we are passing the Domain objects (not specific to your Presentation tier) to the service. your action form serves just as the PT pre- and post-processor. The Business part of creating blogs (possibly, their persisting, etc.) is done by the business service that knows nothing about the presentation tier or any web app, for that matter.Code:public class MyFormAction extends FormAction {
private BlogService blogService ;
@Required
public setBlogService(BlogService svc) {
blogService = svc;
}
// you need to make sure that this method is called on the submit event - in your state definition XML
public createBlogs(equestContext context) {
MyBlogsCommand blogCmd = (MyBlogsCommand) super.getFormObject(context);
blogService.createBlogs(blogCmd.getBlogs()); // it may have to return results, you decide...
... do whatever you need here to process the results
return success(); // this will return the control to your flow executioner
}
}
I've had a look at the JPetStore example and I see how your comment reflects with the example.Quote:
Originally Posted by constv
I was wondering, isn't this a bit of an overkill? The way I look at it now is that one would have a Command object, a Data Transfer Object and an Entity object. The web form data is mapped to a Command object. Then you map the Command object to a Data Transfer object that is then fed through to the Service layer. If it is a Rich Domain design, the DTO would then be fed to the Entity object where the business rules are kept and use the data from the DTO.
I see from your comment and the JPetStore example that you can encapsulate Business objects within a Command object. To me, I would never refer to a Business object from within the Presentation layer, full stop.
Wouldn't it be more efficient to, say, have a DTO that the Service layer and the Domain objects/entities can understand and work with. This way, the Domain objects/entities are never visible to the Presentation layer?
For my next question I'll be open to opinion on this. If the Presentation layer can only talk to the Services using DTO with the example I've provided, is it safe to use the same DTO as a Command object?
So, as a (high level) example I would implement it as:
The DTO...
Code:package org.mydomain.example.domain.blog;
public class BlogForm {
private String name;}
public String getName() {
return this.name;}
public void setName(String name) {
this.name = name;}
The Domain entity...
Code:package org.mydomain.example.domain.Blog
import java.util.Date;
import org.mydomain.example.dao.blog.BlogDao;
public class Blog {
private BlogDao blogDao;..// Other properties can be provided.private String name;private Date datePosted;..public String getName() {
return this.name;}
public void setName(String name) {
this.name = name;}
public String getDatePosted() {
return this.datePosted;}
public void setDatePosted(Date datePosted) {
this.datePosted = datePosted;}
..public void post(BlogForm blogForm) {
// A very basic business rule...this.setName(blogForm.getName());this.setDatePosted(new Date());..this.blogDao.save(this);}..}
The Service interface...
Code:package org.mydomain.example.service;
public interface BlogService {
abstract void postBlog(BlogForm blogForm);}
The Service implementation...
Code:package org.mydomain.example.service.standard;
import org.mydomain.example.domain.DomainFactory;
import org.mydomain.example.domain.blog.Blog;
import org.mydomain.example.domain.blog.BlogForm;
import org.mydomain.example.service.BlogService;
public class StandardBlogService implements BlogService {
private DomainFactory domainFactory;..
public void postBlog(BlogForm blogForm) {}
// A very basic business workflow.Blog blog = DomainFactory.newBlog();..blog.post(blogForm);..}
The controller...
Code:package org.mydomain.example.application;
import org.mydomain.example.domain.blog.BlogForm;
import org.mydomain.example.service.BlogService;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.SimpleFormController;
public class PostBlogController extends SimpleFormController {
private BlogService blogService;..public ModelAndView onSubmit(Object command) {}
..this.blogService.postBlog((BlogForm) command);..return new ModelAndView(this.getSuccessView());}
Shah.
Shah,
to answer your question, I would have to step back to the root of our other discussions about the basic architectural concepts, the definitions of Domain, services, etc.
Your concept of Domain Objects differs from mine, or from the authors' of JPetStore, for that matter. I define a functional Domain as a combination of 1) business entities and 2) operations that may be performed over those entities. So far, our views are similar, I think. But when it comes to the implementation, I strongly disagree with the school of thought you seem to belong to. I am not saying it is bad, and I do believe that objects must encapsulate both data and behavior. However, I also believe that being an "object purist" is not necessarily a good thing. Not all functionality that may be applied to a class must live on that class. The most essential concept of the art and craft of software engineering - and the most disregarded, unfortunately - is the concept of de-coupling things that are better off managed separately. Not melting things together allows creating flexible software, it gives you options to use the same things in various contexts without having to repeat yourself, without creating more work and hurdles for yourself. "Object puritanism", or, perhaps "object zealotry", is a dangerous thing.
There are reasons why the great Edger Dijkstra all but rejected the idea of OO! He once said:
:)Quote:
Object-oriented programming is an exceptionally bad idea which could only have originated in California.
Now, let's not dismiss his point of view without thinking. Dijkstra spent all his professional life promoting elegance and correctness in programming, and he knew a thing or two about that! His contributions to Computer Science and programming languages are colossal! Every serious programmer absolutely must read Dijkstra's The Humble Programmer article (the ACM Turing Lecture) before they read any modern flavor-of-the-day books on coding practices and design patterns! That may open some people's eyes on what programming should be all about, what testing is really for (not for ensuring the absence of the bugs, if that's what you are tempted to say!) , and many other things...
Of course, all of us here in this forum are devoted Java programmers, and we appreciate the value of good OO design. I can't speak for Dijkstra and interpret why exactly he personally disliked the idea of OO. Perhaps he saw the danger in the concept that could easily be misinterpreted and taken to the extreme? I'd completely understand that. I definitely disagree with the notion that any object should always be literally self-contained, which implies that it should store the business logic applied to it. I believe (and so do many others) that objects that represent entities must encapsulate their properties/attributes and only the behavior essential to the object's definition - without any business-specific operations that may or may not be applied to that entity. In other words, it is not appropriate to put application-specific business operation into an all-purpose entity. Things like that should be externalized. Therefore, my idea of domain entities is closer to your idea of a DTO or value objects, but not exactly that. I do believe that such entities must implement the kind of behavior without which the entity may not be considered valid and usable. For example, a UsZipCode class may implement zip validation, parsing of the input data, splitting the zip into 5-digit code, 4-digit extension, or representing itself in several different ways: 5-, 9-, or 11-digit code, etc. All of such functionality is essential to defining a US Zip Code concept but it has nothing to do with the world outside the class itself. Nothing in such Zip Code class depends on, or makes assumptions about, how the objects of the class will be used in applications. This is the most essential point that I am trying to make. The entity definitions must be decoupled from any external operations that may be performed on the entity instances. The necessity in such operations (use cases) may come and go, but the domain entity objects will remain what they are - regardless of how they used.
That is why, I clearly separate the concept of a domain entity, and a domain service. Note that I said "domain service". That's because I see a service as a software module that implements use cases/operations in a particular functional domain. For example, the User service implements user-related use cases and operates on User domain entities. Therefore a DOMAIN concept covers both: entities and operations, but keeps the two separate.
In your interpretation, the business operations and data are molded together, and then you add a notion of a pure VO/DTO. The advantage of my approach is that I can apply any necessary business logic at any time to my domain entity objects (that carry the data and the encapsulated behavior that only describes the nature of the object, without the business logic). I define the business operations in dedicated services that implement use cases. I can add or remove service operations, but the Domain Object model remains the same. I don't need a separate layer of DTOs, and, most importantly, it is absolutely valid to expose the domain entity objects to the presentation tier (controllers/presenters.) In fact, that is how it should be! And that's what you saw in JPetStore. For example, if you decide that your application needs to use a notion of a User with some of the user-management functionality, you add the User component (e.g. user.jar) as a dependency for your application. Your front-end actions/controllers are aware of the User class and other entity classes defined in that component. They are also aware of the UserService (or UserManager) class that implements some user management functionality. You have no problem injecting that manager instance into your front-end controller, so why would you object the Controller being exposed to the entity classes that are also defined by the same User component? (Remember, in other our discussions I explained how to package classes by functionality, not by type; if yo do that you will always end up with a single independent module that defines both the service API and entity objects.)
So, there you have it. The Controller receives the application-specific form/command object and maps the data to the domain entity that is recognized by the service (manager), and makes the call to the business method on the service to execute the business operation. Very simple. No additional DTOs, no "gateways". It's nothing new. It's just all about separating things and responsibilities that do not necessarily belong together. It is ok to have a "manager/service" object vs. stuffing everything into a "domain [entity] object." Once you wire something in, you are stuck with that. You should never make assumptions about what operations will and should be performed on an object. A desk is a desk. You can't force everyone to use it in the same way. Some people use desks for work, for writing, for reading, some folks eat at their desks, some might want to do things you won't imagine... None of those behaviors have anything to do with the concept of a desk itself, even though they are often applied to desks... You get my point, right? ;)
Good discussions.
.. and a lengthy discussion at that. Excellent feedback constv!
I used to code in the similar fashion in that the behaviour and domain objects are separate. It certainly was easier to design with as it is a common design approach, and many examples are provided (even today) using this design.
So if I had to redesign the example I've provided I would create a BlogManager class where the behaviour is implemented. This leaves the Blog object entity plain as vanilla, with attributes and properties. I'd still keep a separate Service implementation as its main purpose is to encapsulate the business rules and should be kept thin. This is a commonly used design and you'll find that it is adopted within Fortune 500 companies and it is classed as an Anemic Domain Model. But one day found out the hard way that this design an anti-pattern. :(
There are so many references available that talk about the Anaemic Domain Model:
Martin Fowler talks about it http://martinfowler.com/bliki/AnemicDomainModel.html. It strongly encourages that state and behaviour should be at the Domain layer. It does emphasise that the Anaemic Doamin Model is commonly used, however.
From the Substance of Code, there is a blog item that talks about 'From Anemic to Rich Domain Model' and shows the differences and its opinion between the two.
There is an item on Wikipedia that talks about Anemic Domain Model (http://en.wikipedia.org/wiki/Anemic_Domain_Model) and describes the benefits and liabilities of using this design.
From the Spring reference document look up section 6.8.1., which talks about 'Using AspectJ to dependency inject domain object with Spring' (http://static.springframework.org/sp...atconfigurable).
So there is certainly a demand for Rich Domain Model and already there are designs and approaches that help achieve this.
Personally I feel that there are a few (yet very crucial) differences between Anemic and Rich Domain Model. I took the time in understanding how to transition from Anemic to Rich and once I nailed it actually made a lot more sense.
I've worked on a number of projects where I initially used the Anemic Model and then later used the Rich Model. I must say that using Rich Domain Model is actually quite good, and it is easier to design with UML.
To summarise, do I currently accept Anemic Domain Model? Of course! Even if the Anemic Domain Model is an anti-pattern, one cannot ignore that it is still commonly used design. So I do accept both designs, but my current preference is the Rich Domain Model.
Thanks for providing the link to Dijkstra's article.
Shah.
Shah,
thanks for the reply! If you noticed, my approach is somewhere in between. I have tried to underline the point that entity objects must have behavior (I never said that they should be plain vanilla data beans.) However, my point is that the behavior that belongs on the object should be the kind that unequivocally defines the entity. I do not believe that you should put any possible behavior you may think of into the object itself. Your objects must be as generic and reusable as possible. As I have said, I want my entities stay the same regardless of the use cases they may participate in - now or in the future. The ease and clarity of the design, implementation, and future maintenance is much more important to me than following some flavor-of-the-day pattern that is considered the right one by some "purist" but makes my architecture rigid and less flexible. Yes, services and managers add some procedural aspect to the overall architecture. But you can't - and there is no need to - eliminate that from any architecture. If it was good for Dijkstra, it's good for me. So, I prefer a reasonable mix - for the sake of clarity, flexibility, maintenability, and efficiency. Which behavior belongs in the entity, and which belongs in a manager object is always a matter of the specifics of the entity in question.
P.S. Now, perhaps we should stop using the words like "manager" that have a very "procedural" undertone, and simply say that you separate the concepts of the entity and business objects. An entity is what I have described before, the business object is an object that abstracts the specific business behavior that may include manipulating some entity objects. End of the argument. Everything is objects. We just de-coupled the behavior that should be hard-wired from the behavior that is subject to change and depends on use cases, environment, etc, and, most importantly, may or may not be needed. The bottom line - no matter what anyone says - there is always a clear difference between a subject (any subject) and things that can be done with that subject. It would be insane to argue with this simple fact. So why, oh why, would anyone think of combining the two into a single monolithic concept in the software world? That's just not right...
Thanks for the feedback constv. This has been an interesting discussion.
And certainly this will keep me on my toes. I'll be looking again into this design concept to get a ful understanding and the benefit it provides.
I guess finding the right balance that one feels comfortable with is what counts. As long as the design one proposes addresses the problems found in developing software and is reasonable I personally say that it is acceptable.
I can see there will be slight variances on designs between solutions and this makes it all exciting to discover new techniques along the way.
Many thanks again constv for this discussion. I'm sure this won't be the last of our discussions. :)
Shah.
thanks for this awesome discussion.
btw should submit values be inside the command object. (this count as user inputted value right).