views:

65

answers:

1

I'm struggling to choose appropriate names for my actions. I want to distinguish between actions that return a view to:

  1. Create
  2. Edit
  3. Edit-Create

Here is what I have so far:

Create --> Show the Empty Form for Create  
Add    --> Receives data from Create and Save New Entity  
Edit   --> Shows Existing Entity in a form for editing  
Update --> Saves the changes on an existing Entity  
???    --> Shows the form for either editing or creating depending on the 
           situation  
Save   --> Either saves or updates the entity depending on whether the entity 
           already exists or not.  

So, What would be an appropriate name for the action that Shows the Create/Edit view, which sends its data to Save.

I had considered CreateEdit since it's clear and specific, but I'm not sure. Any suggestions?

+3  A: 

I typically use Create() for adding a new entity and Edit() for editing one.

I overload the GET & POST methods and add an [HttpPost] attribute to the one that receives the data, e.g.:

public ActionResult Create()
{
    // this one renders the input form
    ...
    return View();
}

[HttpPost]
public ActionResult Create( MyViewModel model )
{
    // this one accepts the form post
    if ( ModelState.IsValid )
    {
       ...
       return RedirectToAction( ... );
    }
    return View( model );
}

This convention makes it easy to find related methods.

Mike Scott
So, Create (New Entity), Edit (Alter Existing), Create/Edit --> ???Also, whate are the pros and cons to combining these actions into an overload?
bzarah
Create/Edit works fine if you can pass an empty model to the GET method and can detect that the entity is new in the POST method, e.g. by checking for a zero ID. However, my controller methods are so small and are functionally different - i.e. the create method just maps the view model object to a new entity and saves it, whereas the edit method loads the entity and just maps the model on to it - there's no need to save the update if you're using a change-tracking ORM such as NHibernate.
Mike Scott
We're using NHibernate here as well, so saving a new entity and updating an existing one can be done seamlessly from the same method. I'd love to get your thoughts on the pros and cons of overloading the methods for the "Show" and "Persist" actions. I feel like separate action names for each would result in a clearer API. That being said, ASP.NET MVC has built in extensibility through ActionMethodSelectorAttributes, and @bzlm has made the point that this is more RESTFful.
bzarah
How seamlessly? When you load your entity from a session, there's no need to update it - it's automatic. My session management is handled for me in the global.asax.cs so I don't even think about explicitly updating entities. I use persistence by reachability for new entities - see [Don't Create Aggregate Roots](http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/) by Udi Dahan. Don't know what you mean by show and persist actions. Do you mean detail and create/edit?
Mike Scott
No need to get into an NHibernate discussion here. The "Show" is the showing of the form for editing and the persist, well, that's the the action that validates and persists the data sent to the server.
bzarah
The Show action method would normally show some details of an entity for viewing only - thus a GET. Persistence would be by Create or Edit with a POST. REST would require that Create is a PUT and Edit is a POST but since browsers don't support PUT, POST is used.
Mike Scott