Вы можете написать связующее для пользовательской модели:
public class JobModelBinder : DefaultModelBinder
{
public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
{
// fetch the job id from the request
var jobId = controllerContext.RouteData.Values["id"];
// fetch the currently connected username
string user = controllerContext.HttpContext.User.Identity.Name;
// Remark: You might need an additional step here
// to query AD and fetch the email
// Given the job id and the currently connected user, try
// to fetch the corresponding job
Job job = FetchJob(jobId, user);
if (job == null)
{
// We didn't find any job that corresponds to
// the currently connected user
// => we throw
throw new HttpException(403, "Forbidden");
}
return job;
}
private Job FetchJob(int jobId, string user)
{
throw new NotImplementedException();
}
}
, а затем ваш контроллер:
public class JobsController : Controller
{
[Authorize]
public ActionResult Show([ModelBinder(typeof(JobModelBinder))]Job job)
{
return View(job);
}
}
Пользовательская модель подшивки также может быть зарегистрирована в Application_Start
:
protected void Application_Start()
{
...
ModelBinders.Binders.Add(typeof(Job), new JobModelBinder());
}
, который упростит действие вашего контроллера:
public class JobsController : Controller
{
[Authorize]
public ActionResult Show(Job job)
{
// If we get to that point it means that the
// currently connected user has the necessary
// permission to consult this view. The custom
// model binder would have populated the Job model
// and we can safely pass it to the view for display
return View(job);
}
}
Еще одним преимуществом этого подхода является то, что вы можете внедрить зависимости в конструктор вашей пользовательской связки моделей. Возможно, эти зависимости потребуются при попытке установить связь с AD и базой данных.