Дизайн модели в ASP.NET MVC

Question

У меня есть постоянные проблемы с дизайном модели в MVC. В основном для всех моих проектов требуются некоторые объекты, которые должны быть созданы, отредактированы и удалены. Большинство из этих объектов имеют некоторые общие свойства, такие как дата создания, измененная дата, автор, модифицированные и в некоторых случаях даже более описательные свойства являются общими. Из-за этого у меня есть одна таблица DB для их хранения. Например, таблица «Документы», и мы храним в ней счета-фактуры, котировки и другие деловые документы. Я использую Entity Framework v4 для ORM, где мы, в конечном итоге, получаем объект Document.

Как изменить этот объект или создать отдельный класс DocumentViewModel для поддержки нескольких типов документов с общими свойствами (так что должна быть реализована определенная форма наследования или реализация интерфейса)? Помимо идентификации разных типов документов, мне также необходимо иметь некоторые типы, чтобы иметь разные правила аннотации данных (атрибуты).

Например, в таблице документов есть столбец PayDate. Тип документа Счета требует, чтобы PayDate предоставлялся, но тип документа Котировка не используется.

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

Answer 1

Считаете ли вы, что делать Документы предприятие аннотация?

С стороны БД у вас будет Документы таблица, содержащая только поля, разделяемые всеми счетами-фактами/итомами. В этом поле будет IDENTITY PK - например DocId.

В других таблицах, дополнительные мета-данные, специфичные для данного документа могут быть сохранены, а ПК является (нетождества) поле DocId, который также является ФК к Документы таблицы.

На стороне EF, Документов становится абстрактной сущности и другие объекты наследуют от этого объекта. Это позволяет создать хорошую парадигму ОО и сделать ваш код более надежным.

В настоящее время мы используем эту схему (EF4/SQL Server).

Ваш сценарий звучит очень похоже на наш - рассмотрим использование абстрактных классов.

EDIT

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

Как комментарии к вашему состоянию Q, у нас мало знаний о вашем домене, поэтому сложно сделать обоснованные мнения. Лично я решил сделать свой объект аннотация, потому что для некоторых функций требовалось «смешанная сумка» предметов, которые нужно вернуть за один удар. Конечно, есть другие способы сделать это (например, хранимая процедура), но это позволяет хорошо владеть интерфейсом между моим пользовательским интерфейсом (кстати, MVC) и моим уровнем обслуживания.

как это работает - вот как я получаю одного Сообщение:

// var is strongly-typed to a "Post" 
var somePost = repository.FindSingle(10); 

Вот как я получаю смешанный мешок сообщений:

// var is strongly-typed to a "ICollection<Post>". 
// "Title" is a property on my "Post" abstract POCO 
var mixedBagOfPosts = repository.FindAll<Post>(p => p.Title = "Some Title"); 

Вот как я получаю сборник «Обзоры» (ребенок почты):

// var is strongly-typed to a "ICollection<Review>" 
// "Rating" is a property on my "Review" POCO (derived from Post) 
var reviews = repository.FindAll<Review>(r => r.Rating == 5.00); 

Кикер мое хранилище осуществляется с обобщениями, а параметр типа обеспечивает безопасность типов:

ICollection<T> FindAll<T>(Expression<Func<T,bool>> predicate) where T : Post 

И это реализовано так:

return myContext.Posts.OfType<T>.Where(predicate).ToList(); 

OfType вызывает внутреннее соединение в T (который является дочерней таблицей), поэтому возвращаются только те записи.

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

Кроме того, вам не нужно идти со всей экспрессией-предикатом, мне это нравится, потому что это сводит к минимуму количество методов на моем интерфейсе и дает полную мощность запроса моим контроллерам, в то же время обеспечивая запросы отложили до уровня обслуживания, но не дальше.

Если вам это не нравится, вы можете, конечно, иметь регулярные параметры (название строки и т. Д.).

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

Answer 2

Много раз вы можете поместить таблицу в свою EF-модель и просто переименовать ее в объекты, которые вам нужны. Просто удалите столбцы, которые вам не нужны.

Например, введите объект документа ... теперь переименуйте его в счет-фактуру. Теперь добавьте еще один, и назовите его Quotation ... в Quotation, нажмите PayDate и нажмите клавишу удаления. Вы можете настроить все, что хотите! Вы можете сделать то же самое с другими ORM, просто потребуется немного больше работы. С NHibernate вы вручную создадите Модели, а затем сопоставляете их с одной и той же таблицей, но только сопоставляете то, что вам нужно.