Как должна выглядеть модель в ASP.NET MVC?

Alexandr Kononov
Дата: 04.05.2010 13:45:42
На днях возник ожесточенный ‘религиозный’ спор с начем на тему что такое модель в MVС.

На мой взгляд, модель - это некоторый класс, содержащий данные, передаваемые вьюхе, и методы для работы с этими данными (валидация, чтение/запись в БД и т.п.). То есть модель знает о данных все, и как их получить, как их проверить, сохранить, какая еще справочная информация может понадобится при отображении этих данных и как ее получить. Главный плюс мне видится в том, что в результате мы получаем единый класс, способный предоставить данные и произвести над ними некоторые действия. Для него легко будет написать тесты, при его использовании не нужны дополнительные классы.

Мнение начальника немного другое. С его точки зрения модель – это набор классов. Один из них хранит данные для отображения (он и передается вьюхе), другой умеет получать и сохранять эти данные, содержит валидаторы и т.п. То есть происходит разделение кода отвечающего за хранение данных и выполняющего работу с БД и содержащим прочую бизнес-логику (валидоаторы и т.п.) Его главный аргумент - то что в его варианте вью в принципе не может получить к методам бизнес-логики, которые находятся в другом классе.

Как всегда бывает в 'религиозных' спорах каждый остался при своем мнении. Стало интересно, а что думают на этот счет другие люди? Кому какой подход больше нравится и почему? Может есть и третий вариант?

P.S. В качестве иллюстрации сделал 2 тестовых проекта (простое отображение/редактирование данных). Проекты отличаются только реализацией моделей и соответственного их использованием в контроллерах (TestMVC сделан с использованием модели содержащей данные и методы бизнес-логики в одном классе, в TestMVC2 бизнес-логика и данные разнесены по разным классам)
Starlex
Дата: 04.05.2010 14:28:20
Alexandr Kononov,

Вы уверены, что статическая переменная в этом куске кода - это правильно? Не перепишут ли юзера данные друг у друга при одновременном обращении?

public class IntItemDataAccessor
    {
        private static List<IntItem> _items = new List<IntItem>();
...

Вообще теория говорит о том, что представление должно знать о модели, а модель не должна знать о представлении :) И представлений может быть множество на одну модель.
Alexandr Kononov
Дата: 04.05.2010 15:11:52
Starlex
Alexandr Kononov,

Вы уверены, что статическая переменная в этом куске кода - это правильно? Не перепишут ли юзера данные друг у друга при одновременном обращении?

public class IntItemDataAccessor
    {
        private static List<IntItem> _items = new List<IntItem>();
...


Статическая переменная - это исключительно эмуляция базы данных и не более. В реальном приложении ее конечно не будет.

Starlex

Вообще теория говорит о том, что представление должно знать о модели, а модель не должна знать о представлении :) И представлений может быть множество на одну модель.


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