I'm currently working on an MVC 3 project using Ninject as my DI, the business objects are stored in a separate assembly. I'm running into an issue with the controller parameters, when posting back for CRUD operations I'm getting the error "Cannot create an instance of an interface". I am aware that you can't create an instance of an interface, but it seems like the only way I can get around this is to use a custom model binder and pass the FormCollection through. This seems really messy and I want to keep as much type specific code out of the project as I can - hence interfaces everywhere and Ninject to DI the concretes. Not only does custom model binding seem messy - won't I also lose my DataAnnotations?
Some code to describe what I have:
public ActionResult Create()
{
// I'm thinking of using a factory pattern for this part
var objectToCreate = new ConcereteType();
return (objectToEdit);
}
[HttpPost]
public ActionResult Create(IRecord record)
{
// check model and pass to repository
if (ModelState.IsValue)
{
_repository.Create(record);
return View();
}
return View(record);
}
Has anyone run into this before? How did you get over it?
Thanks!
but it seems like the only way I can get around this is to use a custom model binder
A custom model binder is the correct way to go. And by the way you should use view models as action arguments, not domain models or interfaces.
Not only does custom model binding seem messy - won't I also lose my DataAnnotations?
I don't know why you think that a custom model binder would make things messy. For me it's a great way to separate mapping logic into a reusable class. And, no you will not lose DataAnnotations. They will work perfectly fine on the concrete instance that the custom model binder would return.
Data passed to controllers action are simply holders for values. There shouldn't be any logic in them so there is nothing to decouple from. You can use concrete types (e.g Record) instead of interface (IRecord)
I made the same simple mistake. Ninject injects parameters into your constructor, but you added parameters to the Index Controller action.
It should look like this:
public class HomeController : Controller
{
private IRecord _record;
public HomeController(IRecord record)
{
_record = record;
}
public ActionResult Index()
{
ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application. " +
_record .HelloWorld();
return View();
}
}
Make sense?
Related
I'm investigating Web Api in ASP.NET vNext using the daily builds. In a web api 2x project, I use HttpParameterBinding and ParameterBindingAttribute in some situations (see http://bit.ly/1sxAxdk); however, I can't seem to find either in vNext. Do/will these classes exist? If not, what are my alternatives?
Edit (1-22-15):
I want to be able to serialize a complex JS object to a JSON string, put the JSON string in a hidden form field (say name="data"), submit the form, and then bind my parameter to that JSON object on the server. This will never be done by a human, but rather by a machine. I also want this very same mechanism to work if the JSON is sent directly in the request body instead of form data. I also need this to work for several different types of objects.
I've been able to accomplish this scenario in Web Api 2.2 in a few different ways, including a custom ModelBinder; however, I remember reading an MSFT blog post that suggested to use a ModelBinder for query string binding, formatters for request body, and HttpParameterBinding for more general scenarios. Is it okay to read the request body in a ModelBinder ASP.NET 5, or is there a better mechanism for that? If so, then case closed and I will port my ModelBinder with a few minor changes.
I'm not sure that IInputFormatter will work for me in this case either.
Here are two rough approaches
Approach 1:
A quick and dirty approach would be to start with a Dto model
public class Dto
{
public Serializable Result { get; set; }
public Serializable FromForm
{
get { return Result; }
set { Result = value; }
}
[FromBody]
public Serializable FromBody
{
get { return Result; }
set { Result = value; }
}
}
public class Serializable
{
}
And an action method
public IActionResult DoSomething(Dto dto)
{
// Do something with Dto.Result
}
Then write a custom model binder for Serializable, that just works with Request.Form this way you never actually read the body yourself, and Form only reads it if it of type Form.
The down side of this is that ApiExplorer will not provide correct details (but I think since this is none-standard you are going to be in trouble here anyways).
Approach 2
You can alternatively just use the code from BodyModelBinder and create a custom binder for Serializable type above, that first tries to get it from the Form, and if it fails tries to get it from the Body. The Dto class in that case is not necessary.
Here is some pseudo code
if (inputType is yourtype)
{
if (request.Form["yourkey"] != null)
{
Use Json.Net to deserialize your object type
}
else
{
fall back to BodyModelBinder code
}
}
With this approach you can make it generic, and ApiExplorer will say the way to bind the type is unknown/custom (we haven't decided on the term yet :) )
Note:
Instead of registering the model binder you can use the [ModelBinder(typeof(customBinder))] attribute to apply it sparingly.
Here is a link to the BodyModelBinder code.
There is a new [FromHeader] attribute that allows you to bind directly to http header values if that is what you need.
https://github.com/aspnet/Mvc/issues/1671
https://github.com/aspnet/Mvc/search?utf8=%E2%9C%93&q=fromheader
I'm still reasonably new to ASP.NET MVC 3. I have come across view models and their use for passing data from a controller to the view. In my recent question on model binding two experts suggested that I should use view models for model binding as well.
This is something I haven't come across before. But both guys have assured me that it is best practise. Could someone maybe shed some light on the reasons why view models are more suitable for model binding?
Here is an example situation: I have a simple class in my domain model.
public class TestParent
{
public int TestParentID { get; set; }
public string Name { get; set; }
public string Comment { get; set; }
}
And this is my controller:
public class TestController : Controller
{
private EFDbTestParentRepository testParentRepository = new EFDbTestParentRepository();
private EFDbTestChildRepository testChildRepository = new EFDbTestChildRepository();
public ActionResult ListParents()
{
return View(testParentRepository.TestParents);
}
public ViewResult EditParent(int testParentID)
{
return View(testParentRepository.TestParents.First(tp => tp.TestParentID == testParentID));
}
[HttpPost]
public ActionResult EditParent(TestParent testParent)
{
if (ModelState.IsValid)
{
testParentRepository.SaveTestParent(testParent);
TempData["message"] = string.Format("Changes to test parents have been saved: {0} (ID = {1})",
testParent.Name,
testParent.TestParentID);
return RedirectToAction("ListParents");
}
// something wrong with the data values
return View(testParent);
}
}
So in the third action method which gets invoked when an HTTP POST arrives I used TestParent for model binding. This felt quite convenient because the browser page that generates the HTTP POST request contains input fields for all properties of TestParent. And I actually thought that's the way the templates that Visual Studio provides for CRUD operations work as well.
However the recommendation that I got was that the signature of the third action method should read public ActionResult EditParent(TestParentViewModel viewModel).
It sounds appealing at first, but as your models and view actions get increasingly complex, you start to see the value of using ViewModels for (most) everything, especially input scenarios.
Case 1 - Most web frameworks are susceptible to over-posting. If you are binding straight to your domain model, it is very possible to over-post data and maliciously change something not belonging to the user. I find it cleaner to bind to an input view model than have long string lists of white lists or black lists, although there are some other interesting ways with binding to an interface.
Case 2 - As your input grows in complexity, you'll run into times when you need to submit and validate fields not directly in the domain model ('I Agree' checkboxes, etc)
Case 3 - More of a personal thing, but I find model binding to relational domain objects to be a giant pain at times. Easier to link them up in AutoMapper than deal with MVC's modelbinder for complicated object graphs. MVC's html helpers also work more smoothly against primitive types than deep relational models.
The negatives of using ViewModels is that it isn't very DRY.
So the moral of the story is, binding to domain models can be a viable solution for simple things, but as the complexity increases, it becomes easier to have a separate view model and then map between the two.
In a recent project - i've hit an unexpected snag.
A class with simple public fields (note not properties) doesn't seem to want to play nice with the
ASP.net MVC 3.0 model binder.
Is this by design?
besides changing the fields to properties - any options here?
update
The reason for the simple fields (instead of properties) is because I'm working with a shared library between MVC and a Script Sharp project. Script sharp supports properties - but it becomes a mess with javascript in the view (using knockout.js)
So despite what i'd love (which is to just use properties) i'm using public fields in my dto classes.
I wanted to avoid having multiple definitions of the same classes. sigh
Is this by design?
Yes, only properties with public getter/setters work with the default model binder.
besides changing the fields to properties - any options here?
That's what you should do as you should be using view models anyway. And view models are specifically designed for the views. So changing the fields to properties is the correct way to do. Now if you don't follow good practices and try to use your domain models as input/output to actions then you will have to write a custom model binder that works with fields. It will be a lot of work though.
I know it's against the c# team's philosophy, but I think fields are clean in poco classes. Seems like less moving parts to me. Anyway,
Here's a model binder that will load fields. It's fairly trivial. Note that you can use a new object with Activator.CreateInsance or start with an existing object as a starting point. I was using Yes/No dropdowns for bool, you may have check boxes, in which case unfortunately you'll have to loop through fieldinfos and look for missing form inputs b/c html doesn't submit form items if it's a false checkbox.
~/Binders/FieldModelBinder.cs
using System;
using System.Reflection;
using System.Web.Mvc;
namespace MyGreatWebsite.Binders
{
public class FieldModelBinder : DefaultModelBinder
{
public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
var obj = controllerContext.HttpContext.Session["CurrentObject"];// Activator.CreateInstance(bindingContext.ModelType);
var form = controllerContext.HttpContext.Request.Form;
foreach (string input in form)
{
FieldInfo fieldInfo = obj.GetType().GetField(input);
if (fieldInfo == null)
continue;
else if (fieldInfo.FieldType == typeof(bool))
fieldInfo.SetValue(obj, form[input] == "Yes");
else
fieldInfo.SetValue(obj, Convert.ChangeType(form[input], fieldInfo.FieldType));
}
return obj;
}
}
}
Startup.cs
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
ConfigureAuth(app);
ModelBinders.Binders.Add(typeof(FieldModelBinder), new FieldModelBinder());
}
}
Usage
[HttpPost]
public ActionResult MyGreatAction([ModelBinder(typeof(FieldModelBinder))] MyGreatProject.MyGreatNamespace.MyGreatType instance, string myGreatParameters)
{
DoSomethingGreatWithMyInstance();
return View();
}
I am sure there has to be an easy way to do this, but I just cant seem to get my head around it.
I am using the MVCContrib Grid control to display a number of grids in a 3 tier application I am working on (ASP.NET MVC3 PL -> BLL -> DAL). I also am using Ninject to automatically inject all my dependencies.
The problem I am having is that I am using a grid model to display grids in my Views like this:
#Html.Grid(Model).WithModel(new UserGridModel(Html)).Attributes(id => tableName)
and have the corresponding grid model defined:
public class UserGridModel : GridModel<User> {
public UserGridModel(HtmlHelper html)
{
Dictionary<int, string> userStatuses = /*TODO: GET ALL USER STATUSES*/;
Column.For(user => user.ID);
Column.For(user => html.ActionLink(user.Email, "Edit", new {id = user.ID})).Named(DtoResources.UserDto_Email);
Column.For(user => user.FirstName);
Column.For(user => user.LastName);
Column.For(user => userStatuses[user.StatusID]);
}
}
Now I need to inject a service into this model so it can pull in all of the applicable statuses from the service (BLL) level. Currently just to make sure this would work, I exposed the IKernel in the Bootstrapping code and just IKernel.Get() but I don't think that is the cleanest way to get it. I would use constructor injection, but if I put the IUserStatusService as a parameter in the constructor, I can't figure out how I would get Ninject to inject the correct parameter when I call new UserGridModel(Html) in the view without explicitly using the IKernel there.
I am either missing something or wiring this up all wrong. Either way I'm stuck ... any help? What is the proper way to get an instance of my service through Ninject
In my opinion the cleanest solution to your problem is to change your controller so that it creates a model that already contains the user status as string so that no convertions is required in the view. I would do as littel as possible in the view and grid model.
Another possibility is to property inject the service to your view an pass it to the grid model. But as I mentioned this way you are introducing logic to your view.
I've this scenario in my application:
Controller1
.GetItems()
Model1
.GetItems()
Controller2
.GetCurrentUser()
Model2
.CurrentUser
In this scenario Controller1.GetItems() calls Model1.GetItems() method. Model1.GetItems() method needs to know (for example) what is the role of the current user to build the correct list of items, and it should get it from the Model2.CurrentUser property (that stores the cached information about the current user).
Is it a good practice to acces a model from another model?
Thanks,
Regards
You are going to run into some arguments about the best way to do this, but at the end of the day, you have two options. Either you can have the model pull the information it needs from the other model or you can have the controller pass the information needed.
Based upon what I have read, as long as the model does not have any controller logic or view logic you are good so there is nothing wrong with having the model know about other models. However, others have argued that having the controller pass the information that is needed makes the code a bit easier to document since you can see that the model requires information from somewhere else. At the end of the day though, I see both as being valid and which one you choose to use will likely come down to personal preference.
Design - Controller Provides Data
ModelOne
User GetCurrentUser()
ModelTwo
Items[] GetItems(User)
Snippet - Controller Proivdes Data
Controller {
function doWork() {
User user = ModelOne.GetCurrentUser();
Items[] items = ModelTwo.GetItems(user);
}
}
Design - Model Gets Data
ModelOne
User GetCurrentUser()
ModelTwo
Items[] GetItems()
Snippet - Model Gets Data
ModelTwo {
Items[] GetItems() {
User user = ModelOne.GetCurrentUser();
...
}
}
Controller {
function doWork() {
Items[] items = ModelTwo.GetItems();
}
}
If your second model is going to referenced often by your first, you could compile your model classes into a separate library?
I think you shouldn't have references between models, the right way is to use the controller for this link. So in your case you could pass the CurrentUser as a parameter in the GetItems method.