Tech Off Thread

11 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

MVC with EF formatting

Back to Forum: Tech Off
  • User profile image
    cheong

    Say I have two Razor MVC form that contains the same List of records from EF. One of the field is decimal value. In the first form we only need 2 decimal places precision, and 4 decimal places for the second form. In both form they're binded to a EditorFor HtmlHelper.

    Normally I'd set DisplayFormatAttribute to make it work, but it surely doesn't fit the 2 forms case. What should I do now?

    Btw, I think formatting is a Presentation Layer thing in MVC concept, it's a bit weird to me that I have to define it in Data Layer.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    JohnAskew

    View <=>ViewModel<=>Model  

    Formatting display for a View is the responsibility of its ViewModel.

    I will argue for each View there should be one and only one ViewModel.

    In this way, your business object, as a property within both ViewModels, can supply the list and each ViewModel can then format the data specifically for its View in the propety getter. You should be able to format much display in the View xaml binding expressions... e.g. 'StringFormat="C"'...

    I believe it is a mistake to use ViewModels as business objects instead of using ViewModels to simply resurface Models for consumption by Views. I prefer business objects that work locally to orchestrate Models so that they are cogent and testable; they are not a part of the EF schema. This business object API that orchestrates logic upon the Models is produced from Test-First Design, in the best case scenario. ViewModels are for the single purpose of providing formatted display for binding to the View.

    Here is a link you might use http://visualstudiomagazine.com/articles/2011/10/01/mvvm-in-5-minutes.aspx

     

  • User profile image
    ScanIAm

    @JohnAskew:

    I've broken it up even more:

    View <==> ViewModel (inherits from EditModel) <==> DTO <==> Model

    Edit Model contains any user selections while the rest of the ViewModel contains lookup data and dropdown contents and such that doesn't need to be passed back and forth.

    DTOs are just better organized versions of the model that makes it easier to abstract the datamodel away from the database.

  • User profile image
    ScottWelker

    @John/Scan (cheong): Isn't the question specifically with regard to (ASP.Net) Model-View-Controller (MVC) not Model-View-ViewModel (MVVM)? Are we sending cheong "down the rabbit hole" Wink

    http://www.orbifold.net/default/?p=550

    http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

     

  • User profile image
    JohnAskew

    ViewModel or Controller, this is where the formatting can be set as needed, for example a property can be added therein (which takes the same source as you've decorated with DisplayFormatAttribute) which resurfaces the data for consumption with the desired alternate format. This property's getter will reformat the source for the view; and this can be within either a ViewModel or Controller.

    Don't allow acronyms to instill doubt for concepts which are so-fundamental-as-to-cause-second-thoughts...

    http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

    "The following has been a summary of several of the patterns that have emerged in dealing with view models. Although these have all been in the context of ASP.NET MVC, the problem with how best to deal with view models is also an issue with other frameworks like web forms as well. If you are able to bind directly to domain model in simple cases, that is the simplest and easiest solution. However, as your complexity grows, having distinct view models gives you the most overall flexibility."

  • User profile image
    cheong

    @JohnAskew:Nice article. Will definately take a look.

    @ScottWelker: Yup, my project is in MVC and not MVVM. But don't mind shifting to a new programming model if it makes more sense. It's the fact that I couldn't find a way to do formatting in presentation layer under the MVC model that puzzles me, as that would kind of defeat the purpose of having MVC there.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    ScottWelker

    @cheong/John: K, I'll back out and let those with the greater expertise handle this. Not my forte - yet Wink Best of luck with your project!

     

  • User profile image
    blowdart

    View models also guard against silliness like mass assignment, and, of course, give you a nice place to check the current user is allowed to actually view the resource in question.

  • User profile image
    itsnotabug

    i think this is where i'm having some difficulty with mvc. i've gone through the samples but it seems like in order to do anything substantial (real-world), i'd end up having to go mvvm in practice. i'm sure i'm missing something but the attributes on the controller seem to control too much that could possibly be going on in the view like conditional string formatting, validation, localization. would partial views help in the case?

  • User profile image
    JohnAskew

    , itsnotabug wrote

    i think this is where i'm having some difficulty with mvc. i've gone through the samples but it seems like in order to do anything substantial (real-world), i'd end up having to go MVVM in practice. i'm sure i'm missing something but the attributes on the controller seem to control too much that could possibly be going on in the view like conditional string formatting, validation, localization. would partial views help in the case?

    Consider adding ViewModels in the mix. The article below exactly addresses the issue when a Controller might best be split apart into View-centric ViewModels where all common code for them remains in the Controller. It is simply another object layer, the ViewModel is solely concerned with what the View displays. Remember the Principle of Seperation of Concerns, (fundamental, primary), should compel us to break code-dense Controllers into "single-purpose" classes; ViewModels can be split out from a heavy Controller class. These ViewModels, then, may turn around and ask the Controller to run important or shared code that is beyond the "just-format-this-data-for-display" code you want to put into ViewModels.

    http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

    In my experience partial or composite Views are much more difficult to manage... Microsoft Patterns & Practices takes the lead with that, in my world view: http://compositewpf.codeplex.com/ You could model your own code from their mature code base.

     

  • User profile image
    itsnotabug

    thx for the links john!

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.