Asp.net MVC Architecture

Question

Я подхожу к концу своего первого проекта MVC, и я не слишком доволен тем, как я построил объекты модели, и я ищу некоторые идеи о том, как их улучшить.

Я использую репозитории для каждой таблицы БД с помощью методов Get, Save, Delete и т. Д. Репозитории используют Linq2Sql для доступа к БД.

Я осуществляю сопоставление объектов Linq2Sql с объектами модели MVC, в основном это очень много от 1 до 1 сопоставлений.

Моя проблема: я не думаю, что мои объекты модели MVC были достаточно гранулярными, и я, вероятно, передаю больше данных туда и обратно, чем нужно.

Например, у меня есть таблица пользователей. Администратор может редактировать данные пользователей, как и сам пользователь, поэтому я считаю, что у меня действительно должны быть объекты AdminUserModel и UserModel, где «AdminUserModel» имеет больший набор значений (например, IsEnabled).

Итак, мой большой вопрос в том, какие архитектуры используют люди в дикой природе, чтобы сопоставить многие аналогичные связанные объекты Модели через слои в БД?

Любые примеры архитектурных решений, которые любой может предложить за пределами NerdDinner?

благодарит заранее!

Answer 1

В случае вашей модели пользователя вы должны использовать наследование вместо 2 отдельных моделей. Таким образом, вы можете использовать код, который был создан для пользователя в тех, которые унаследованы от него.

Тип используемой модели полностью зависит от того, что вы хотите с ней сделать. Хорошая вещь может состоять в том, чтобы взглянуть на шаблоны и попытаться заставить шаблоны работать, которые необходимы для вашей ситуации ...

Answer 2

Обычно я использую наследование наложения в своих моделях. Обычно у меня есть базовый класс сущности, который будет иметь id, datecreated, valid и любые другие поля, которые совместно используются объектами (publishStatus, заблокированные и т. Д.). Если потребности быть, вы можете создать другие базовые классы Наследования от лица: лицо сущность, сущность продукта и т.д.

таким образом, вы можете иметь общий репозиторий базы, с ограничениями в Entity или IEntity, я считаю, что функции большинства организаций CR не нужно гораздо более поведение, чем это предусмотрено в общей базы (возможно, вам нужно будет добавить несколько дополнительных методов получения для некоторых типов)

в вашем случае AdminUser может наследовать от User