ASP.NET MVC View Calling Model

Published Sep 06, 2017
ASP.NET MVC View Calling Model

You can read my previous constructive article v2:

https://www.codementor.io/kennyblau/statelessness-data-access-layer-and-entity-framework-bnvr99lbd

So we know not to call the model directly from a view. Weren't we also told in school not to use 'goto' statements. There are always exceptions to the rule. If you never used 'goto' statements in your COBOL, then you would have one giant loop, for the entire program which would be pure spaghetti.

Can you please tell if we are actually calling into the model after leaving the controller, before the view gets rendered? If I have a method called FormatData() and it resides in the view, FormatData() gets called before the view is rendered. The actual view is what gets sent to the client, not the cshtml file. The view for the client is what shows up in their browser view source.

There are three ways that I am going to describe, where calling from view directly into model may be acceptable. All three are considered 'SetViewCondition' methods. To get field data, we can call into the model. This is c# server side code getting a return value from a method and using it in c# embedded in view. To call FormatData type methods. This might be a Value attribute on an Html.TextBoxFor. And, collections that are used for client side tables. eg DataTables.

On new projects, you can keep out cshtml method calls. Hindsight is always 20 20.

If you have already coded method calls in your view, and you have a deadline, then just leave your code alone.

Furthermore, mathematically, changing code is contradicting. Case one, getting data from model at server binding, rendering view time. This is where we are in c# embedded code in the view and are calling a server side method to return a value. In the controller we have a model with fieldA value A. If we take a snapshot of fieldA into a ViewBag, and if code changes fieldA to value B. Our view will have stale data. The ViewBag was assigned before the data changed.

Secondly, and globally, FormatData() at the server binding, rendering view time, instead of calling FormatData(), in the view can cause a Math inconsistency. Model has fieldA with value of A. This is where FormatData() can be put on Html.TextBoxFor attribute 'Value'. We apply the FormatData() on fieldA. Say, truncate 4.666 to 4.66. If the ModelState.IsValid = false, the formatting of the data will not be displayed by the view. Rule Unless ModelState.Clear is called, which has reprocussions, eg false positive passing validation, or all data is valid, 'A' will display its formatting change correctly. Rule Continued If data does not pass all validations, 'A' will NOT be formatted.

Using FormatData(), requires us to use the Value html attribute. If we ridding ourselves of FormatData() [case two] and applying the formatting directly on the model, we need to remove this Value attribute. More work against the addage "Finished code is good code"

DataTables is an excellent, client side grid, which takes a collection as input. In the collection, a field may require formatting, with a call to the server side FormatData() method at server binding, rendering view time. If we format the data to push to a grid, we have to re-write our LINQ statement to format a column in our collection rows. This re-write, is enough to prounounce "Finished code is good code" obsolete.

Another point to consider, is that all your Controller Actions that feed into your view need to have their ViewBags set. All of my code is in one place, and this is an additional requirement.

I know this article is difficult to digest, but when I become a mentor, you can become my student and learn.

Discover and read more posts from kenny blau
get started