ASP.NET MVC 2 LINQ-to-SQL сгенерированные классы и проверка модели

Question

Я просто хочу убедиться, что правильно понимаю лучшие практики для ASP.NET MVC2 с LINQ-TO-SQL.

Пожалуйста, исправьте меня, если я ошибаюсь в любом из следующих пунктов:

• LINQ TO SQL генерирует для вас классы на основе ваших таблиц
• Сгенерированные классы - это Модели
• Это модели, которые мы должны использовать в представлениях
• Если мы хотим добавить проверку в модели, мы расширяем частичный класс и устанавливаем аннотации данных.Что-то вроде this .

Вообще мой вопрос касается проверки данных.То, что я использовал для , - это создание "теневой" модели для каждого из моих сгенерированных классов LINQ-to-SQL и размещение проверки данных там.Затем в контроллерах я создавал экземпляр «теневой» модели, а также извлекал данные (используя шаблон репозитория).Преобразуется из сущности в теневую модель и передается в представление.Итак, что-то вроде этого (в контроллере):

// Car is class generated by LINQ-to-SQL, based on the Car table
// Use repository class to retrieve the data (Car)
Car car = myDatabaseRepository.GetCar(1);

// CarModel is my 'shadow' model, which has all the data validation.
// For example, it makes sure Year is before 2010 (let's say).
CarModel carModel = new CarModel();
carModel.Year = car.Year;
carModel.Make = car.Make;
carModel.Model = car.Model;

return View(carModel);

Это неправильно, верно (без каламбура) ?Это должно было быть только:

// Car should have been extended (as partial) and data annotation
// should have been in the extended class, rather than a whole separate
// model class.
Car car = myDatabaseRepository.GetCar(1);
return View(car);

Верно?

Answer 1

Я думаю, что лучше всего иметь ViewModel (то, что вы назвали "теневой" моделью), которая используется для передачи только соответствующей информации модели данных в представление и включения метаданных проверки пользовательского интерфейса. Вы также можете использовать библиотеку, такую ​​как AutoMapper , чтобы копировать значения, а не кодировать каждое из них вручную.

Табличный = модельный подход может работать в очень простых сценариях (несколько таблиц + простой пользовательский интерфейс, точно соответствующий схеме базы данных). Чтобы потом избавить себя от боли, рекомендуется использовать ViewModels.