Entity Framework Database First Property Validation - asp.net-mvc

I'm using EF database first and with MVC.
I'm wanting to add some validation on a property to compare its old value to its new one and report a validation error to the MVC ModelState if there is a problem.
This would be easy enough using code first and validating using 'set' on the property. However I can't do this using database first because its auto generated.
I've looked at using IValidatableObject and the validate() method however by then the value has already been changed on the property so I can't see the old one anymore to compare to.
Short of creating a method to pass the new value into first to check it, I can't think of another way.
Any suggestions?
Thanks

If you want to compare a new value to an old value then you are going to have to grab the values from the database first (before updating) and compare them:
[HttpPost]
public ActionResult Update(MyObject myObject)
{
var oldObject = db.Objects.FirstOrDefault(o => o.Id == myObject.Id);
//Compare oldObject.Value to myObject.Value
}
You could still use IValidatebleObject and pass in the objects that you need to keep that logic outside the controller.

Its not the ideal and this has started illustrating some of the weaknesses in Model and DB first but here's how I ended up doing it.
I decided to change the property in my model so that set was private and then create a separate method in the partial class to set the value. The validation is then all done in that method.
Thanks for your help anyway

Related

Can you reuse a LINQ datacontext in an ASP.NET MVC application with strongly typed views

I am somewhat confused on how to properly use LINQ in combination with an ASP.NET MVC strongly typed view.
My situation is as followed.
1) I retrieve a single object through LINQ
2) I pass this LINQ object to a strongly typed view. (edit form)
3) The user submits the form and the controller receives the LINQ object.
So my questions are:
1) Is the object the controller method receives after the submit still tight to the original datacontext or is it a newly created instance?
2) What is the preferred way to store the updated values in the database using LINQ. If it is still tight to the original datacontext a simple call to SubmitChanges() would be sufficient. But how to maintain the datacontext?
I would like to be able to save these data objects without having to use really ugly linq update statements. (Like retrieving the row again and manually update its values)
Any help, insights and preferably code samples would be appreciated.
Regards,
Dennis
You should fetch the existing object again, and update it, somthing like:
public ActionResult Edit(int ID)
{
DataEntity entity = _service.GetMyEntity(ID);
UpdateModel(entity);
//Saving code goes here.
return View();
}
The entity that you are talking about retrieving is no longer attached to the data context.
Is the object the controller method
receives after the submit still tight
to the original datacontext or is it a
newly created instance?
It won't be attached to a DataContext at all on Submit.
What is the preferred way to store the
updated values in the database using
LINQ. If it is still tight to the
original datacontext a simple call to
SubmitChanges() would be sufficient.
But how to maintain the datacontext?
The preferred way is to create a new DataContext, retreive the old object from the database, update the fields based on what was submitted to your Form, and then save the updated copy from the new Context.
Use your linq objects to get the data and put it into a POCO (plain old c# object) Model specifically for your view.
Your linq2sql/ef objects can be structured to store data which do not necessarily reflect your views
Your model can be updated and validated by the MVC framework by placing it in the call to the post.
public ActionResult EditPost(EditModel model)
When you have a valid model you can then transfer the data back to the database via your linq2sql/ef objects
if(ModelState.IsValid) // save to db
Create a DataContext when you need to load and save, don't persist it
1) It is a new instance (through model binding feature) and it is not attached.
2) It depends, but the best would be probably new instance using(var context = new DBContext()) etc.
3) The most simple thing is fetch the object, pass in the updated values and SubmitChanges() (as you describe). Other option is described in this article. You create new instance of the object (or you have it from the model binding), attach it to the context and submit changes:
public ActionResult Test(MyModel model)
{
DbContext.Models.Attach(model);
DbContext.Refresh(RefreshMode.KeepCurrentValues, model);
DbContext.SubmitChanges();
}

Is this the correct usage of the ViewModel Pattern?

I'm using NerdDinner as a guide for my first MVC/LINQ to SQL project. It discusses the use of the ViewModel pattern when a View needs data from multiple sources - in their example: Dinners and Countries (serves as the drop down list).
In my application, the problem is a bit different. It's not so much different data, rather data linked via a key constraint. I have a Story table that links to aspnet_users via the UserId key. I would like to have easy access to the UserName for each story.
Since I'm using the repository pattern and returning IQueryable in some cases for deferred execution, I'm struggling with the correct way to shape the data. So I'm using this VideModel pattern right now to make it work but not sure if it's the right way.
Instead of returing IQueryable Story (which wouldn't work since I need the UserName), I'm returning a new custom class UserStory, which has a Story property and a string Username property.
What are your thoughts?
It seems like your question has less to do with MVC as it is simply a question about how to access the story data based on the username string.
Would it be possible to create a view in your database with all the UserStory data, the username, along with userid in it? That way, you could select from the view based on the username you have.
To create the view, you would simply have to do a join between the user table and the userstory table based on the userid.
After that, you could still use the repository pattern with the IQueryable being returned.
If you are wanting to do updates, it would be simple to do since you still have the userid, and would be able to link back to the actual table which would need the update.
If you look at Kigg, you will see that they mess about with the initial model to create custom ViewModels. That's the thing that NerdDinner doesn't cover in any detail. You could create a StoriesWithUserName class that inherits from Stories, but adds a new property - UserName. Then you return that to your View which would inherit from IEnumerable<StoriesWithUserName>
[EDIT]
Oops. Didn't spot that you already did this :o)
Using the repository pattern and returning an IQueryable of Stories is fine. The relationship allows you to access the the username value something like this >>
Assuming you are returning the IQueryable in your model object:
foreach(Story story in Model.Stories)
{
// do something with the value
response.write(story.aspnet_user.UserName);
};
Your Repository method would look like this:
public List<Stories> GetStories(Guid UserId)
{
return datacontext.Stories.Where(u => u.UserId = UserId).ToList();
}
The relationship will automatically provide you with access to the UserName value in the foreach loop i first mentioned. nothing more is required.
I'm not sure why your pagination control failed on Count() though??
Hope this helps

Two-Way-Binding Possible In ASP.NET MVC?

Let's say I have a product object (pretty much empty) and I bind it to a Product view. Then I click update in the view. In my CustomModelBinder my bindingContext.Model is always null on the update request. Is there a recommended way of me retrieving the prior model at this point or do I always have to recreate it?
You have to recreate it from the form fields. The values you bound to the model for the GET are long gone.
perhaps im not understanding your needs to use a CustomModelBinder, but did u concider Data Annotations Model Binder yet?
it even comes with (serverside) validation based on simple statements like [Required] which u can put right inside your model, see this

How do you ignore/persist values in MVC when your view-model doesn't have as many fields as your domain model?

I have a site where I'm using fluentNhibernate and Asp.net MVC. I have an Edit view that allows user to edit 8 of the 10 properties for that record (object). When you submit the form and the Model binds, the two un-editable fields come back in the view-model as Empty strings or as default DateTime values depending on the type of property.
Because I'm also using AutoMapper to map my view-model to my Domain Entity, I cannot just load a fresh copy of my object from the database and manually set the 2 missing properties. Whats the best way to persist those fields that I don't want edited?
One way that does work is to persist the values in hidden Input fields on my View. That works but feels gross. I appreciate any recommendations. Is there a way in my AutoMapper to configure this desired functionality?
UPDATE:
Ok, So I guess I'm not trying to ignore the fields, I'm trying to make sure that I don't persist null or empty string values. Ignoring the fields in AutoMapper does just that, they get ignored and are null when I attempt to map them before Saved to my repository.
The asp.net mvc DefaultModelBinder is extensible, and you can override it to create your own binding schema. But this will involve more work than two "hidden Input fields", which , in my point of view, is not that gross.
You can tell Automapper to ignore the 2 properties:
Mapper.CreateMap<Source, Destination>()
.ForMember(dest => dest.SomeValuefff, opt => opt.Ignore());
Possible related question.
Can you use the AutoMapper.Map overload that also accepts TEntity?!
entity = Mapper.Map(viewmodel, entity);
As long as you do not have the properties on your viewmodel, it won't change the values on your entity. It takes the entity being passed in and applies only the properties from the viewmodel back to the entity.

ASP.Net MVC DefaultModelBinder not binding properties on POST

I'm facing a really strange problem that has me smoked.
I have a fairly simple scenario where I have a strongly typed view that is correctly populated from the controller on the GET, but then when it POSTS the form to the controller, the Reqeust is full of all the right values and right key names for the default model binder to correctly populate one of my model objects, and the DMB creates the correct opject, but it never populates any of the properties, they're all in their default state.
This was working before, the only changes I can think of were that I tried a custom modelbinder (then removed it; double checked to make sure I'm not still using that), and I refactored the model to have a base class with some of the props.
Any thoughts?
A very similar scenario - that the DefaultModelBinder is - essentially - not binding to your model, arrise if you would give your bound model object the same name as one of its properties:
Model
Public Property ArbitraryName1 As Integer
Public Property Answer As String
Public Property ArbitraryName2 As Boolean
View
<p/> ... #Model.ArbitraryName1
<p/> Answer: #Html.TextBoxFor(Function(model) model.Answer)
<p/> ... #Html.CheckBoxFor(Function(model) model.ArbitraryName2)
Controller
<HttpPost()>
Function Index(answer As Model) As ActionResult
' answer is Nothing
End Function
(Using ASP.NET MVC 3)
Got it. The model had been refactored in a way which naturally affected the ability of the mdoel binder to populate it.
The name of your input param do not have to be equal to some property name of the object. Remember that all data coming as an array of name -> value and the default binding use the names for make the relation work.
I had this behaviour arise by moving two properties from the top of the class to further down. I still can't work out why this stopped the binding of a third property from working (so this isn't a solution so much as a 'watch out for') but I repeated the change multiple times and each time the binding went from working to not working.
I also found that after making this change I sometimes had to 'Clean' the solution for the binding to start working again.

Resources