Могу ли я динамически / на лету создать класс из интерфейса, и будет ли nHibernate поддерживать эту практику?

Question

Я немного погуглил, но мне еще предстоит найти решение или хотя бы однозначный ответ на мою проблему.

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

Более конкретный пример:

У меня есть базовый класс / интерфейс ACCOUNT, который содержит коллекцию транзакций.Для каждой компании, использующей мое программное обеспечение, я создаю новую конкретную версию класса, BOBS_SUB_SHOP_ACCOUNT или SAMS_GARAGE_ACCOUNT и т. Д. Таким образом, идентифицирующим значением для класса является имя класса, а не поле в классе.

Я использую C # и Fluent nHibernate.

Итак, мои вопросы:

1. Имеет ли это смысл или мне нужно уточнить больше?(или я пытаюсь сделать что-то, чего ДЕЙСТВИТЕЛЬНО не должен?)
2. У этого шаблона есть имя?
3. Поддерживает ли это nHibernate?
4. Знаете ли вы о каких-либодокументацию по шаблону, который я мог прочитать?

Редактировать: Я думал об этом немного больше, и я понял, что мне ДЕЙСТВИТЕЛЬНО не нужны динамические объекты.Все, что мне нужно, это способ привязать объекты с некоторым идентификатором к таблице через NHibernate.Например:

//begin - just a brain dump
public class Account
{
  public virtual string AccountName { get; set; }
  public virtual IList Stuff { get; set; }
}

... somewhere else in code ...

//gets mapped to a table BobsGarageAccount (or something similar)
var BobsGarage = new Account{AccountName="BobsGarage"}; 
//gets mapped to a table StevesSubShop(or something similar)
var StevesSubShop = new Account{AccountName="StevesSubShop"};
//end

Этого должно хватить для того, что мне нужно, предполагая, что NHibernate разрешит это.Я стараюсь избегать ситуации, когда один гигантский стол получит чертовское преимущество, если в таблицах счетов появится большой объем.Если бы все учетные записи были в одной таблице ... это было бы ужасно.

Заранее спасибо.

Answer 1

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

dynamic bobsSubShopAccount = new DynamicAccount("BOBS_SUB_SHOP_ACCOUNT");
Console.WriteLine("Balance = {0}", bobsSubShopAccount.Balance);

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

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
    if (DatabaseConnection.TryGetField(binder.Name, out result))
        return true;

    // Log the database failure here

    result = null;
    return false; // The attempt to get the member fails at runtime
}

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

Я не использовал NHibernate, поэтому я не могу комментировать с какими-либо полномочиями, как NHibernate будет играть с динамическими объектами.

Answer 2

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

Если вы действительно беспокоитесь о производительности БД, и ваши нагрузки будут такими большими, возможно, вы могли бы взглянуть на разбиение таблицы вместо?Ваши доменные объекты могут легко справиться с созданием ключа раздела, и вам не нужно делать сумасшедшее вуду с NHibernate.Это также упростит вам возможность не делать сумасшедшие вещи на уровне домена в случае, если вы позже измените свои механизмы персистентности.Вы можете создать коллекционные фильтры на своих картах или сопоставить объекты только для чтения с видом.Последний вариант будет немного вонючим в домене.

Если вы абсолютно настаиваете на создании вуду, возможно, вы захотите взглянуть на NHibernate.Я не могу сказать, каково текущее состояние разработчика и совместимость, но это вариант.