MVC View Model handling
No edit summary
No edit summary
Line 1: Line 1:
<html>
<div class="outdated-alert">
<p> <span> ❗🕜 Warning: </span> this article may contain outdated information. Consider before using any descriptions/solutions, otherwise it still can be helpful. <a href="https://wiki.mdriven.net/index.php/MDriven_Product_Line#Synonyms_and_name_changes"> <span> Help : Synonyms and name changes </a>
</p>
</div>
</html>
Even if it is perfectly possible to let MVC use the business objects this way – it is not optimal for a couple of reasons: security, business rules and overall control of information.
Even if it is perfectly possible to let MVC use the business objects this way – it is not optimal for a couple of reasons: security, business rules and overall control of information.



Revision as of 18:28, 2 December 2018

❗🕜 Warning: this article may contain outdated information. Consider before using any descriptions/solutions, otherwise it still can be helpful. Help : Synonyms and name changes


Even if it is perfectly possible to let MVC use the business objects this way – it is not optimal for a couple of reasons: security, business rules and overall control of information.

It is preferred to add a layer of abstraction between the model and the view – the view model. The view model can be described as a perspective or a section or a transformation of parts of the model and it offers a good place to mold information from the model in specific formats – like when combining multiple attributes that builds up an address to a customer in the model to a single string that we may want to present in the view.

It is also likely that in large projects with multiple developers that hold different skills – like model savvy developers and view savvy developers – the model developer might not “trust” the view developer to access only the “correct” or intended part of the model for the task at hand. Then the View model is a perfect way to define each use case / task / view and only hold the information needed.

View models defined in Modlr are described in multiple articles on this site – but the problem until now – was that they always needed to belong to an EcoSpace. This made it impossible for MVC to instantiate them to send back data from a postback to our controller.

How we solved it:

The View models too can now be in Offline mode. They can be code generated for easy static type check and data binding support. They work equally well in MVC, WPF, Silverlight or whatever your choice of UI layer.

The code generated ViewModel has been cleaned up for this release - if you used them earlier you will need to adapt your code (we dropped the “Root” from vm.Root.Attribute so that it is now vm.Attribute. Further more the base class VMClass is no longer inheriting Dictionary<>, if you need your vm to act as a dictionary use the vm.AsDictionary property)

Given this model:

01 - MVC View Model handling.png

I declare a ViewModel:

02 - MVC View Model handling.png

And now I can use the standard MVC scaffolding for creating Views:

03 - MVC View Model handling.png

I also use the standard actions in Visual Studio to create Controllers, but change the base class to EcoController (from Peters Sample). Some controller code examples:

    public class ElaborateVMController : EcoController
    {
        //
        // GET: /Elaborate/

        public ActionResult Index()
        {
          var all=EcoSpace.Extents.AllInstances<ElaborateClass>().
                            Select(o => ElaborateVM.Create(EcoSpace, o));
          return View(all);
        }

        //
        // GET: /Elaborate/Details/5

        public ActionResult Details(string Identity)
        {
          IObject io = EcoSpace.ExternalIds.ObjectForId(Identity);
          return View(ElaborateVM.Create(EcoSpace, io.AsObject as ElaborateClass));
        }

        //
        // POST: /Elaborate/Create

        [HttpPost]
        public ActionResult Create(ElaborateVM offlineElaborateVM)
        {
          try
          {
            ViewModelHelper.ApplyValues(offlineElaborateVM, 
                           ElaborateVM.Create(EcoSpace, new ElaborateClass(EcoSpace)), null);
            if (Commit())
              return RedirectToAction("Index");
            return View();
          }
          catch
          {
            return View();
          }
        }


and example of the scaffolded View code:

@model EcoMVC.ViewModelCodeGen_ElaborateVM.ElaborateVM

@{
    ViewBag.Title = "Details";
}

<h2>Details</h2>

<fieldset>
    <legend>ElaborateVM</legend>

    <div class="display-label">
         @Html.DisplayNameFor(model => model.Attribute1)
    </div>
    <div class="display-field">
        @Html.DisplayFor(model => model.Attribute1)
    </div>

    <div class="display-label">
         @Html.DisplayNameFor(model => model.Attribute2)
    </div>
    <div class="display-field">
        @Html.DisplayFor(model => model.Attribute2)
    </div>

It ends up looking like this:

04 -MVC View Model handling.png
05 -MVC View Model handling.png

Attributes in generated code

Oh – and before I forget – you probably want to decorate the ViewModel attributes with specific MVC attributes like [Required]. In Modlr all tagged values that start with a star “*” is added to the generated code. This:

06 -MVC View Model handling.png

on a ViewModel column, will come out like:

    [System.ComponentModel.DataAnnotations.Required()]
    [GeneratedCodeAttribute("ECO", "6.0.0.0")]
    public string Attribute1 {
      get {

And that will be picked up by MVC as :

07 -MVC View Model handling.png

(Swedish for Field Attribute1 is required)

Taking it further

As I said earlier I am still no MVC expert. I can see the merits to MVC but I am also still confused on all the name matching that is going on behind the scenes. I would be very happy to have someone do a better sample and share with all here…

This page was edited 47 days ago on 02/10/2024. What links here