MVC 3 - Как это вообще будет работать?

Я сделал этот пост более года назад, и я думаю, что имеет смысл обновить его, так как он набирает довольно много просмотров.

Я либо что-то упускаю, либо Microsoft действительно испортила MVC. Я работал над проектами Java MVC, и они были простыми и понятными. Однако это полный беспорядок ИМО. Примеры в Интернете, такие как NerdDinner и проекты, обсуждаемые на ASP.Net, слишком просты, поэтому они «просто» работают. Извините, если это звучит негативно, но это мой опыт.

У меня есть репозиторий и служба, которая обращается к репозиторию. Контроллеры вызывают сервис.

Мой уровень данных НЕ независим от персистентности, поскольку классы были сгенерированы SQL metal. Из-за этого у меня много лишнего функционала. В идеале я хотел бы иметь POCO, но пока не нашел хорошего способа добиться этого.

* Обновление: Конечно, Microsoft ничего не испортила - я сделал. Я не совсем понимал инструменты, которые были в моем распоряжении. Главный недостаток того, что я сделал, заключался в том, что я выбрал неправильную технологию для сохранения своих сущностей. LINQ to SQL хорошо работает в приложениях с отслеживанием состояния, поскольку контекст данных можно легко отслеживать. Однако в контексте без гражданства дело обстоит иначе. Какой будет правильный выбор? Сначала код Entity Framework или код работают хорошо, но что более важно, это не имеет значения. MVC, или интерфейсные приложения не должны знать, как хранятся данные. *

При создании объектов я могу использовать привязку к объектам:

[HttpPost]
public ActionResult Create(Customer c)
{
    // Persistance logic and return view
}    

Это отлично работает, MVC выполняет некоторую привязку за сценой, и все "очень хорошо".

Это не было «Веселым добром». Клиент был моделью предметной области, и, что еще хуже, она зависела от среды сохранения, потому что она была сгенерирована металлом SQL. Что бы я сделал сейчас, так это спроектировал бы свою модель предметной области, которая не зависела бы от уровней хранения данных или представления. Затем я бы создал модель представления из моей модели предметной области и использовал бы ее вместо этого.

Как только я захочу сделать что-то более сложное, например, сохранить заказ, связанный с клиентом, все, похоже, сломается:

    [HttpPost]
    public ActionResult Create(Order o)
    {
        // Persistance logic and return view
    }

Чтобы сохранить заказ, мне нужен Customer или хотя бы CustomerId. CustomerId присутствовал в представлении, но к тому времени, когда он попал в метод Create, он потерял CustomerId. Мне не нравится сидеть и отлаживать код MVC, так как я не смогу изменить его в среде хостинга.

Хорошо, извините, немного поплакать. Теперь я бы создал модель представления под названием NewOrder, SaveOrder или EditOrder в зависимости от того, чего я пытаюсь достичь. Эта модель представления будет содержать все свойства, которые меня интересуют. Автоматическая привязка из коробки, как следует из названия, будет связывать отправленные значения, и ничего не будет потеряно. Если мне нужно настраиваемое поведение, я могу реализовать свою собственную «привязку», и она выполнит свою работу.

Альтернативой является использование FormCollection:

[HttpPost]
public ActionResult Create(FormCollection collection)
{
   // Here I use the "magic" UpdateModel method which sometimes works and sometimes doesn't, at least for LINQ Entities.               
}

Это используется в книгах и учебных пособиях, но я не вижу смысла в методе, у которого есть альтернатива: TryUpdateModel - если это дает сбой или модель недействительна, он пытается обновить его в любом случае. Как вы можете быть уверены, что это сработает?

Автосвязывание с моделями представлений будет работать большую часть времени. Если это не так, вы можете отменить его. Откуда вы знаете, что это всегда будет работать? Вы тестируете его, и вы хорошо спите.

Другой подход, который я пробовал, - это использование ViewModel - объектов-оберток с правилами проверки. Это звучит как хорошая идея, за исключением того, что я не хочу добавлять аннотации к классам Entity. Этот подход отлично подходит для отображения данных, но что вы делаете, когда дело доходит до записи данных?

[HttpPost]
public ActionResult Create(CustomViewWrapper submittedObject)
{
    // Here I'd have to manually iterate through fields in submittedObject, map it to my Entities, and then, eventually, submit it to the service/repository.
}    

** Модель View - хороший путь вперед. Должен быть некоторый код отображения из модели представления в модель предметной области, который затем может быть передан соответствующей службе. Это неправильный способ, но это один из способов. Инструменты автоматического сопоставления - вы лучшие друзья, и вы должны найти тот, который соответствует вашим требованиям, иначе вы будете писать тонны стандартного кода. **

Я что-то упускаю или так должен работать Microsoft MVC3? Я не понимаю, как это упрощает ситуацию, особенно по сравнению с Java MVC.

Прошу прощения, если это звучит негативно, но до сих пор это был мой опыт. Я ценю тот факт, что фреймворк постоянно совершенствуется, появляются такие методы, как UpdateModel, но где же документация? Может пора остановиться и немного подумать? Я предпочитаю, чтобы мой код был последовательным во всем, но с учетом того, что я видел до сих пор, я не уверен, что это правильный путь вперед.

Мне нравится структура. Так много предстоит узнать, и это ' Это не намного интереснее, чем когда-либо. Вероятно, стоит сделать еще один пост о веб-формах. Надеюсь, это поможет.