Question

I have an Action method in an ASP.NET MVC Controller class that handles form posts from a fairly basic ‘create/edit a user’ page. I’m new to MVC so I’ve been following code samples from various Microsoft tutorials, this is how the method looks currently:

[AcceptVerbs(HttpVerbs.Post)] public ViewResult Save([Bind(Prefix = 'ServiceUser')]ServiceUser SUser) {         if (SUser.ServiceUserId == 0) //new service user             ServiceUserHelper.AddServiceUser(SUser);         else //update to existing service user         {             using (ProjectDataContext db = DatabaseHelper.CreateContext())             {                 this.UpdateModel(db.ServiceUsers.Single(su => su.ServiceUserId == SUser.ServiceUserId), 'ServiceUser');                 db.SubmitChanges();             }         }          //return a confirmation view } 

This works fine; however my instincts tell me that the ‘ProjectDataContext…’ code doesn’t belong in the controller. If I were to move the Update functionality to an other class (in the way I have done with the Insert method), I’d lose the convenience of the Controller’s UpdateModel() method, and probably end up having to do something quite verbose to read the existing entity, update its properties, and submit the changes.

So my question is, what is the best way to achieve this? Is there a method similar to UpdateModel() somewhere in LINQ that can merge two entities of the same type together before submitting?

Thanks.

Answer 1

Most people will suggest using the ‘Repository Pattern’ to move that data access code out of the controller (and to enable unit testing with mock objects instead of the real database).

Here are some places to read more:

• Implementation example for Repository pattern with Linq to Sql and C#
• Chapter 1 of Professional ASP.NET MVC (Page 32)

Edit:

I highly recommend reading the entire Scott Guthrie chapter linked above. It has a wealth of good advice in it. That said, here are some relevant examples (excepted from the chapter)…

First, I generally like to have different actions for ‘Update’ vs. ‘Add’. Even if they are the same View to render the form, it generally feels cleaner to have different URLs for POSTing an edit vs POSTing a new record. So, here is what the repository pattern in use looks like in a controller’s update action:

[AcceptVerbs(HttpVerbs.Post)] public ActionResult Edit(int id, FormCollection formValues) {     //get the current object from the database using the repository class     Dinner dinner = dinnerRepository.GetDinner(id);     try     {         //update the object with the values submitted         UpdateModel(dinner);         //save the changes         dinnerRepository.Save();         //redirect the user back to the read-only action for what they just edited         return RedirectToAction('Details', new { id = dinner.DinnerID });     }     catch     {         //exception occurred, probably from UpdateModel, so handle the validation errors         // (read the full chapter to learn what this extention method is)         ModelState.AddRuleViolations(dinner.GetRuleViolations());         //render a view that re-shows the form with the validation rules shown         return View(dinner);     } } 

Here is the ‘Add’ example:

[AcceptVerbs(HttpVerbs.Post)] public ActionResult Create() {     //create a new empty object     Dinner dinner = new Dinner();     try     {         //populate it with the values submitted         UpdateModel(dinner);         //add it to the database         dinnerRepository.Add(dinner);         //save the changes         dinnerRepository.Save();         //redirect the user back to the read-only action for what they just added         return RedirectToAction('Details', new { id = dinner.DinnerID });     }     catch     {         //exception occurred, probably from UpdateModel, so handle the validation errors         // (read the full chapter to learn what this extention method is)         ModelState.AddRuleViolations(dinner.GetRuleViolations());         //render a view that re-shows the form with the validation rules shown         return View(dinner);     } } 

For both examples above, the DinnerRepository looks like this:

public class DinnerRepository {     private NerdDinnerDataContext db = new NerdDinnerDataContext();     //     // Query Methods     public IQueryable<Dinner> FindAllDinners()     {         return db.Dinners;     }     public IQueryable<Dinner> FindUpcomingDinners()     {         return from dinner in db.Dinners                where dinner.EventDate > DateTime.Now                orderby dinner.EventDate                select dinner;     }     public Dinner GetDinner(int id)     {         return db.Dinners.SingleOrDefault(d => d.DinnerID == id);     }     //     // Insert/Delete Methods     public void Add(Dinner dinner)     {         db.Dinners.InsertOnSubmit(dinner);     }     public void Delete(Dinner dinner)     {         db.RSVPs.DeleteAllOnSubmit(dinner.RSVPs);         db.Dinners.DeleteOnSubmit(dinner);     }     //     // Persistence     public void Save()     {         db.SubmitChanges();     } }