В настоящее время это невозможно. Я открыл проблему , не стесняйтесь: +1: it.
С точки зрения тестирования мне кажется, что передача в объекте непосредственно к методу действия является более естественной. Нет никакой потребности заполнить ValueProviderDictionary.
Причина другой подход необходим, состоит в том, что Вы, возможно, должны были бы управлять инстанцированием объекта, который Вы связываете. DefaultModelBinder просто ищет конструктора по умолчанию и называет его.
Но в некоторых случаях, Вы, возможно, должны были бы создать объект сами прежде, чем связать его со значениями формы. Это - то, где UpdateModel играет роль.
Я был бы склонен записать это как так
public ActionResult Update(int id, string name)
{
Person person = PersonRepository.GetByID(id);
//Do any error handling
person.Name = name;
//Do any error handling
PersonRepository.Update(person);
}
Затем протестируйте как так (использующий RhinoMocks)
Person person = new Person();
var mockPersonRepository = MockRepository.GenerateMock<IPersonRepository>();
mockPersonRepository.Expect(x => x.GetByID(1)).Return(person);
mockPersonRepository.Expect(x => x.Update(person));
var controller = new MyController(mockPersonRepository);
controller.Update(1, "Hello");
Assert("Hello", person.Name);
mockPersonRepository.VerifyAllExpectations();
Таким образом, мой ответ, ни одно из вышеупомянутого :-)
Я всегда решил бы прозрачность к контексту не допустить шум в тесты, таким образом, первый метод является лучшим IMO.
Просто любопытный, что Вам нравятся приблизительно волшебные строки по выражениям для поколения HTML. Это - их невидимость к компилятору, сопротивление рефакторингу, или возможно Вы ненавидите intellisense.:) Мм, о, я сделал это теперь, запустился от дебатов темы.
Мне нравится первая опция привязки к объекту модели. Это освобождает контроллер от деталей модели и представления. Поэтому я могу изменить модель и просмотреть по мере необходимости, не влияя на мой контроллер. Тестовая изоляция также становится легче из-за этого.
Для сложных моделей предметной области или представлений, которые только касаются части домена, я создаю модель представления, которая моделирует данные в моих представлениях вместо данных в моем домене. Я затем пишу отображающийся код или использую объектный картопостроитель для отображения модели представления на мою модель предметной области. Это уменьшает связь между моим представлением и моим доменом.
Я должен буду не согласиться с Peter Morris на передающих отдельных параметрах к методу контроллера. Это выглядит хорошим сначала, но быстро становится болью, после того как Вы начинаете работать с большими формами. Кроме того, это увеличение, связывающееся между контроллером и представлением.