Средой разработки является C # 3.5 с базой данных SQL Server 2008 и Entity Framework.
Представьте, что у вас есть класс и таблица с именем Sign, которая представляет собой физический электронный знак, созданный третьей стороной, которым ваше программное обеспечение должно управлять. У вас также есть класс, называемый SignDriver, который обеспечивает фактическое взаимодействие со знаками. Свойства / столбцы Sign представляют настраиваемую информацию, необходимую драйверу Sign для правильного общения со знаками.
Все замечательно, и ты довольно тщательно похлопал себя по спине. Тогда возникает необходимость поговорить с другим знаком. Однако этот знак работает не так, как предыдущий, и требует, чтобы ваш класс и таблица Sign сохраняли дополнительную информацию. Допустим, нужно сохранить 5 новых вещей (столбцов / свойств), но, к сожалению, первый тип знаков не нуждается в этих 5 вещах. Затем вы обнаружите, что если вы хотите контролировать 10 знаков каждого типа, в вашей таблице много значений NULL.
Ваша модель домена будет расти, пока у вас не появится больше классов, таких как Sign, каждый из которых представляет отдельную часть вашего проблемного домена, и у каждого есть соответствующая таблица в вашей базе данных. Каждый класс сталкивается с одной и той же проблемой сбора общей информации о своем типе скважины, но НЕ учитывает специализацию каждого типа скважины вообще.
Вы понимаете, что природа вашей проблемы означает, что будет больше типов знаков для контроля, а также больше типов других ваших сущностей для обслуживания. Вам нужна более расширяемая модель.
Что было бы лучшим путем для такой системы?
Я подробно обсуждал это со своими коллегами и очень хотел бы знать, каков наилучший способ решения такой проблемы. Тем более, что это похоже на проблему, с которой многие люди столкнулись бы в прошлом.
Ниже приведены предлагаемые нами варианты и некоторые замечания по каждому из них:
- Создайте n количество классов «type» и таблицу для каждой сущности, с которой будет делиться отношение 1 к 1.
- Очень наследство-у.
- Большая часть времени при расширении.
- Много таблиц.
- Создайте одну таблицу «расширенных свойств» для каждой сущности для хранения пар ключ-значение.
- Ссылочная целостность.
- Extensible.
- Создайте одну глобальную таблицу «расширенных свойств» для хранения свойств ЛЮБОГО объекта. (схема: entityType, entityId, ключ, значение, dataType)
- Супер расширяемый.
- Не может иметь ссылочную целостность с существующими таблицами.
- Не похоже, что Entity Framework сможет справиться с этим хорошо.
Что бы вы сделали и почему ??
Любая помощь с благодарностью.
Приветствия.