В этой задаче как раз тормоза не пугают
NS>>Ну .. это не совсем то .. что мне программу каждый раз пересобирать при изменении объектов ?
МС>а какие тут парадоксы? версия базы при этом меняется.. выдели отдельный уровень — реализуй его МС>компоненты в отдельной сборке.. иначе не отделаться тебе от тормозов... не везде к сожалению МС>можно реализовать динамику так, чтобы при этом не "посадить" систему...
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, NetStyler, Вы писали:
NS>В этой задаче как раз тормоза не пугают
а не пугает то, что эти наработки из-за тормозов больше никуда не впихнешь и
не прикрутишь? не пугает осознание того, что сделал что-то еле шевелящееся или
то, что в случае увеличения нагрузки в будушем просто встанет колом и начальство
поставит всех раком (извини. ничего личного, но такая перспектива
есть практически у всех).
Здравствуйте, NetStyler, Вы писали:
NS>Ну .. это не совсем то .. что мне программу каждый раз пересобирать при изменении объектов ? NS>
Во-первых — если ты поменял структуру данных то программу тоже скорее всего менять придеться. Во-вторых — зачем пересобирать? Классы в любом случае нужно помещать в отдельную сборку. Вот ее и пересоберешь.
Динамическая генерация нужна только если ты будешь менять структуру базы не закрывая работающей программы. Вот зачем это нужно я и не могу понять.
Здравствуйте, NetStyler, Вы писали:
NS>Хочется создать службу которая: NS>При пересылки ей объекта — знала как положить его в базу. NS>При изменениии структуры БД знала как собрать объект.
Это все xsd делает
NS>При изменении объекта — меняла структуру базы.
А это ты сам и не сделаешь так просто — по практике использования EJB тебе скажу — лучше базу делать руками.
NS>Поддерживаля связи между объектами и т.д.
И это тоже xsd ltkftn
Сразу ты упустил важнейшую вешь — а кешировать ты собираешься?
Пока обойдемся без кеширования.
На самом деле я принимал участие в подобной разработке. (давным давно).
И видел что это работало ... теперь надо как-то воспроизвести. AVK>Здравствуйте, NetStyler, Вы писали:
NS>>Хочется создать службу которая: NS>>При пересылки ей объекта — знала как положить его в базу. NS>>При изменениии структуры БД знала как собрать объект.
AVK>Это все xsd делает
NS>>При изменении объекта — меняла структуру базы.
AVK>А это ты сам и не сделаешь так просто — по практике использования EJB тебе скажу — лучше базу делать руками.
NS>>Поддерживаля связи между объектами и т.д.
AVK>И это тоже xsd ltkftn
AVK> AVK>Сразу ты упустил важнейшую вешь — а кешировать ты собираешься?
Sex Drugs and Linux Rules? Realy? ;-)
ICQ:2489468 MSN:mcloud[at]list.ru
Здравствуйте, NetStyler, Вы писали:
NS>Пока обойдемся без кеширования.
Вряд ли получится
NS>На самом деле я принимал участие в подобной разработке. (давным давно). NS>И видел что это работало ... теперь надо как-то воспроизвести.
Я сам небольшой проектик на дотнете делал. Преобразователь в БД от него лежит на http://xobjects.narod.ru
Здравствуйте, NetStyler, Вы писали:
NS>Доброго времени суток! NS>Возник вопрос: NS>Как формировать классы динамически? NS>Нужно для создания объектной БД под .NET. NS>Конечно, у меня у самого есть кое-какие соображения связанные с сериализацией в XML, но хотелось бы послушать умных людей. NS>Или может, кто посоветует, что почитать… буду очень благодарен.
Почитай статью здесь, может
что-то и полезное написали.
Ни в коей мере не претендуя на звание "умного человека", выскажу своё мнение — возможно, окажется полезным. На мой взгляд, можно определить абстрактный класс, в конструкторе прописать логику создания на основе атрибутов полей и методов, определить эти самые атрибуты. А во время исполнения просто генерить наследников и добавлять поля с заданными атрибутами. Не буду утверждать, что решение оптимальное, но похожую задачу неадвно я решал именно так.
Здравствуйте, NetStyler, Вы писали: NS>Доброго времени суток! NS>Возник вопрос: NS>Как формировать классы динамически? NS>Нужно для создания объектной БД под .NET. NS>Конечно, у меня у самого есть кое-какие соображения связанные с сериализацией в XML, но хотелось бы послушать умных людей. NS>Или может, кто посоветует, что почитать… буду очень благодарен.
Здравствуйте, Low IQ Bastard, Вы писали:
LIB>Ни в коей мере не претендуя на звание "умного человека", выскажу своё мнение — возможно, окажется полезным. На мой взгляд, можно определить абстрактный класс, в конструкторе прописать логику создания на основе атрибутов полей и методов, определить эти самые атрибуты. А во время исполнения просто генерить наследников и добавлять поля с заданными атрибутами. Не буду утверждать, что решение оптимальное, но похожую задачу неадвно я решал именно так.
Ну хоть кто нибудь объясните — зачем во время выполнения?
Здравствуйте, AndrewVK, Вы писали:
AVK>И все таки — зачем?
Если быть точным — смысл был не в генерировании самого класса во время выполнения (их исходники как раз генерились автоматически), а в упрощении работы — не писать каждый раз конструктор, методы и т.д. — свести генерацию к созданию наследника, указанию полей и атрибутов. Ну и такой же подход можно использовать для генерации во время выполнения.
Здравствуйте, Low IQ Bastard, Вы писали:
LIB>Если быть точным — смысл был не в генерировании самого класса во время выполнения (их исходники как раз генерились автоматически), а в упрощении работы — не писать каждый раз конструктор, методы и т.д. — свести генерацию к созданию наследника, указанию полей и атрибутов. Ну и такой же подход можно использовать для генерации во время выполнения.
Понятно. Но тут тебя ждет другая засада — в этом случае тебе придется сам код генерить прямо в опкодах. ИМХО лучше сгенерить и скомпилировать исходники. Плюс возможность просмотреть генеренные исходники иногда очень удобна. И большинство родных утилит генерируют исходники, исключение составляет только tlbimp.
Здравствуйте, kreek, Вы писали:
K>ICustomTypeDescriptor и PropertyDescriptor дадут возможность такие объекты отображать в гриде или использовать датабиндинг.
Да в принципе их можно при этом и через PropertyDescriptor вызывать в лучшем виде. Вот только для статического вызова это доступно не будет. Разве что если вызов делать из JScript.NET.
Кстати, об этом можно статейку написать... Если интересно.
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
NS>>Создание объектной БД.
VD>А может проще взять готовую? Ну Каше например.
Не Влад, ребяты имеют ввиду создание ОО прослойки, вроде EJB или Castor. Вот только еще не знают сколько при этом надо сил положить чтобы получить приемлемое быстродействие.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не Влад, ребяты имеют ввиду создание ОО прослойки, вроде EJB или Castor. Вот только еще не знают сколько при этом надо сил положить чтобы получить приемлемое быстродействие.
Вот я и говорю. Готовая ООБД будет куда лучше и проще.
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте, kreek, Вы писали:
K>>ICustomTypeDescriptor и PropertyDescriptor дадут возможность такие объекты отображать в гриде или использовать датабиндинг.
VD>Да в принципе их можно при этом и через PropertyDescriptor вызывать в лучшем виде. Вот только для статического вызова это доступно не будет. Разве что если вызов делать из JScript.NET.
VD>Кстати, об этом можно статейку написать... Если интересно.
Сории за непонимание статического вызова, вот только если грид читает метаданные о объекте, то ему это все можно подсунуть в рантайме, т.е он это скушает. Пока я писал предидущее предложение, догнал, что ты подразумеваешь под статическим вызовом — т.е. это, то что отображает IntelliSense? тогда можно VB.NET для позднего связывания. Или я тут смешал разые понятия?
А статья нужна людям! Кстати есть наработки по этому поводу.
