Как реализовать разные типы класса: наследование, интерфейс или свойство класса? - PullRequest
Новая
       21

Как реализовать разные типы класса: наследование, интерфейс или свойство класса?

1 голос
/ 19 февраля 2012

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

Я создаю функциональность сообщений для приложения MVC.

Существует два типа сообщений:

  1. Публичные сообщения
  2. Личные сообщения

Единственное отличие состоит в том, что публичные сообщения имеют поля даты ValidFrom и ValidTo. Я пробовал следующее:

Способ 1, интерфейс Интерфейс сообщения. Два класса PrivateMessage и PublicMessage, которые реализуют интерфейс. PublicMessage имеет два дополнительных свойства. Сопоставил его с двумя разными таблицами с помощью структуры лица.

Способ 2, наследование Создайте базовый класс сообщений, который имеет все поля. Создайте два класса, которые наследуют базовый класс. Можно сопоставить класс сообщения с БД, поэтому у меня есть только одна таблица для хранения записей. Кажется, я не могу сопоставить интерфейс с EF Code.

Метод 3, свойство Enum для указания типа сообщения 

    public enum MessageType
    {
        Public = 1,
        Private = 2,
    }

У меня просто есть один класс сообщений, но добавьте поле, чтобы показать, какой это тип сообщения. Карты легко на одну таблицу, и легко для поиска сообщений типа «Public». Я должен сделать мини-обертку вокруг enum, потому что EF не создаст для нее поле в БД.

Достаточно ли двух полей свойств для обоснования двух разных классов? Поиск в двух таблицах базы данных для непрочитанных сообщений немного неэффективен?

Есть ли правильный способ сделать это?

Сначала я использую Entity Framework Code 4.3.

Ответы [ 2 ]

2 голосов
/ 19 февраля 2012

Платформы ORM обычно решают проблему наследования тремя способами: 1. Одна таблица для всех объектов: в этом подходе есть одна таблица, и каждый конкретный класс будет использовать одну и ту же таблицу.Будет использован дискриминатор, чтобы узнать, какая запись относится к какому классу.2. Одна таблица для каждого конкретного объекта: для каждого конкретного объекта в базе данных будет соответствующая таблица, и у каждого объекта есть своя карта. Каркас не знает, что эти объекты являются частью иерархии наследования.необходимо) 3. Одна таблица для каждого объекта (конкретного или абстрактного): в этом подходе общие данные хранятся в таблице, которая сопоставляется с базовым абстрактным классом, и каждый конкретный объект будет иметь отдельную таблицу, в которой хранятся свои собственные данные, и есть одна дляодна связь между этой таблицей и ее родительской таблицей. В родительской таблице снова необходим дискриминатор, чтобы показать структуру, записи которой относятся к какому объекту.

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

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

1 голос
/ 19 февраля 2012

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

1) Вы можете иметь 1 сущность Message, которая содержит все поля и дополнительный столбец IsPublic 2) Вы можете иметь 2 сущности PublicMessage и PrivateMessage, сохраненные в 2 таблицах 3) У вас может быть модель наследования TPT или TPH, где у вас есть Message в качестве базового класса PublicMessage и PrivateMessage

Вопрос о том, что использовать, это больше о том, какую бизнес-проблему вы пытаетесь решить,Вы упоминаете, что поиск по двум таблицам неэффективен.Итак, я предполагаю, что у вас есть представление о том, где один человек может видеть как личные, так и публичные сообщения.Если вы можете, лучше оптимизировать после того, как у вас возникнут проблемы с производительностью (и данные для ее поддержки).

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

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

...