Расширение компонента с дополнительными свойствами

Question

Итак, я думаю о создании простого компонента, который я буду использовать в различных проектах. Компонент предоставляет класс (скажем, автомобиль), который я использую во многих проектах. Компонент также имеет такие вещи, как основные виды для перечисления различных автомобилей и сохраняет свои собственные данные в базе данных через Entity Framework.

Теперь мой вопрос: как мне расширить этот компонент автомобиля между проектами? Большинство автомобилей в разных проектах имеют очень похожие свойства, но все они имеют некоторые дополнительные. Итак, как мне добавить эту дополнительную функциональность (или просто свойства) к компоненту таким образом, чтобы я мог просто обновить DLL, содержащую компонент, если я позже улучшу базовый компонент? И как мне сделать компонент «осведомленным» о дополнительных столбцах в его db?

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

Как вы, наверное, можете сказать, я совершенно новый для всего этого. Так что все и всякие советы очень ценятся!

Answer 1

Если по модели EF вы имеете в виду файл EDMX, то ответ, скорее всего, невозможен. Вы можете получить новый компонент из существующего в другом проекте/решении, но вы не можете расширить EDMX = вы должны создать новый EDMX для новой модели компонента в каждом проекте, добавляя его настройки. EDMX является сопоставлением, и если вы изменили класс или базу данных, вы должны определить новое сопоставление и потому, что EDMX является XML-файлом, он не может быть унаследован таким же простым способом, как и с классом (на самом деле существует только один способ повторного использования существующего EDMX, но он очень ограничен и очень прост в использовании, потому что он не поддерживается дизайнером в Visual Studio).

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

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

Еще одна проблема связана с ObjectSet/DbSet. Если базовый контекст использует что-то вроде:

public ObjectSet<Car> Cars { get; set; } 

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

Answer 2

Может быть я missunderstood что-то, но вы можете иметь, например:

//Component.DLL 
public class Component 
{ 
    //basic functionality 
} 

//CarComponentDLL 
public class CarComponent : Component 
{ 
    //extend component for cars 
} 

//HorseComponentDLL 
public class HorseComponent : Component 
{ 
    //extend component for horses 
} 

сейчас, различные проекты используют различные расширения, как CarComponent или HorseComponent как этот

Component mycompo = new HorseComponent(); 

здесь я использую расширенный для лошади версии моего компонента. Итак, Я знаю, какой вид лошади, связанный с филдами, нуждается в лошади, чтобы иметь возможность доступа к БД.

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

Надеюсь, я ответил на ваш вопрос.