Statelessness, Data Access Layer, and & Entity Framework
ASP.NET Webforms seems superior to MVC, in one area: Viewstate. MVC, has ViewBag and ViewData, but nothing that holds the size of a large serialized object of Viewstate. Tempdata is actually session state, and our concern here is with a load balancer, server affinity is required, which denounces the idea of a load balancer in the first place.
The only good reason to use Tempdata, is where your object matrix is huge, and you want to keep the user on the same page after a post. For example, a user enters 80 fields and clicks 'submit'. The server redirects to a HTTPGET action, so the user can not refresh the page and post twice. With the redirect, in order to keep the user on the same page, if that is your design, then you can use Tempdata to send data from post, to get, to user.
Let's get back to Viewstate substitutes. Let me first advise the reader that hidden fields in MVC, can contain what was viewstate in webforms. And let me further advise that query strings also work like viewstate. But hidden fields and query strings save small amounts of data compared to Viewstate.
So, in ASP.NET MVC, despite size limitations, ViewBag, ViewData, Tempdata, hidden fields, and query string can all ve Viewstate substitutes. Tempdata is only necessary will large objects, described below. Tempdata is the only state method mentioned here that uses state.
DAL & Entity Framework
So you use Entity Framework. You probably use View Models and map the data to a data access layer for create/read/update/and delete operations. A separate view model with attribute decorations, such as [required] fields, seem to work well with the post/get/post PGP, pattern (PGP pattern not explained here). Well, there actually is a way to use native entities and have partial classes that are used to decorate fields with attributes.
You can do the aforementioned strategy by using this post from stack overflow. I give full credit to the other authors for coming up with this metatdata solution: http://stackoverflow.com/questions/14059455/adding-validation-attributes-with-an-entity-framework-data-model
Now, we a left with a problem of cascading add/updates/ and deletes that we need to be aware of and the solution is easy. When we go to add a row into a table, unwanted cascading will occur. See Julie Lerman's article https://msdn.microsoft.com/en-us/magazine/dn166926.aspx
The solution that I came up with is to subclass (talked about below) the edmx dbcontext savechanges method and throw an exception if you are peforming an operation on more than a single node. In order to ensure single node operations, please copy referential integrity foreign to primary key relations, and null these relations, before performing an entity framework operation. Finally, the node back in place.
- An edit product example: We have a list of products with relationship category. Save off the category node. Null the category node. Update the product. Put back the category node.
In the global.asmx in the start of the application, use reflection to check for the existance of the subclass and throw an exception if it does not exist. In the TT files of the edmx, make sure to have the subclass method, and have a readme file to explain the situation. The readme next to the edmx will tell the developer to add the subclass. Also, the program will have an exception if the subclass doesn't exist.
The only problem with this design is the large size of the objects and the mandatory use of tempdata session state and the required sticky session affinity for the web server.
So in conclusion, my Entity Framework model should only be used where the design of a web site requires a huge amount of data fields in a single form.
I know this is just an overview and a tutorial explanation is required. Please sign as my student and I can go into full detail.
The ModelState.IsValid() aside: If you use native entities with many relationships, and you want to use IsValid to validate only a portion of your your entities, you can easily create Clear methods, that remove unwanted "node arms" from participating in the validation.