Здравствуйте, kreek, Вы писали:
K>Сории за непонимание статического вызова, вот только если грид читает метаданные о объекте, то ему это все можно подсунуть в рантайме, т.е он это скушает. Пока я писал предидущее предложение, догнал, что ты подразумеваешь под статическим вызовом — т.е. это, то что отображает IntelliSense? тогда можно VB.NET для позднего связывания. Или я тут смешал разые понятия?
Я не знаю потянет ли VB.NET это дело. Но даже если и поянет, то вызов будет динамическим. Т.е. с помощью PropertyDescriptor и в рантайме. Во время компиляции VB.NET не будет знать что это за тип.
Под статическим вызовом я понимаю нормальный код на том же VB.NET или шарпе. Так например от этого объекта нельзя будет унаследоваться или нельзя будет просто считать свойство. Т.е. можно будет сделать так:
K>А статья нужна людям! Кстати есть наработки по этому поводу.
object c = new Class2();
Type t = c.GetType();
pd = pdc["DinTestStr"];
pd.SetValue(c, "Свойство DinTestStr");
Console.WriteLine(pd.GetValue(c).ToString());
Или (возомжно):
Dim c as Object = new Class2()
Console.WriteLine c.DinTestStr
Но нельзя будет написать:
Dim c as Class2 = new Class2()
Console.WriteLine c.DinTestStr
или
Class2 c = new Class2();
Console.WriteLine(c.DinTestStr);
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Так можно описать базовый класс, который помимо Custom Type Definition будет напрямую предоставлять доступ к свойствам, типа, string or ValueType {get, set}SimpleValue[SimpleValPropertyName] & Business_Object {get, set}RefValue[RefValPropertyName]
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте, kreek, Вы писали:
K>>Неа, охота свою инфраструктуру иметь, на основе которой клепать и клепать приложения
AVK>А зачем свою? Чем не устраивают существующие? Сколько вобще существующих видел?
Пару видел (названия не помню, одна под ДотНет, кажись DotNetPark.сом, другая визуальная под Джаву), для крупного проекта нужна своя, не хочу на уверсальности многое терять.
Здравствуйте, kreek, Вы писали:
K>Пару видел (названия не помню, одна под ДотНет, кажись DotNetPark.сом, другая визуальная под Джаву), для крупного проекта нужна своя, не хочу на уверсальности многое терять.
Даже если писать свою тебе как минимум нужно ознакомиться с теми решениями что предлагает индустрия. Ты просто еще не представляешь какой геморой тебя ждет.
Здравствуйте, kreek, Вы писали:
K>Неа, охота свою инфраструктуру иметь, на основе которой клепать и клепать приложения
Ну тогда начинай с своей СУБД. Так инфраструктура будет полнее.
Ну или не выпендривайся и используй ДатаСеты из адо.нэт или вообще рекорсеты из обычного адо. Ну а на клиенте можешь и обертку сделать, шоб все було в ОО-стиле.
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kreek, Вы писали:
K>Так можно описать базовый класс, который помимо Custom Type Definition будет напрямую предоставлять доступ к свойствам, типа, string or ValueType {get, set}SimpleValue[SimpleValPropertyName] & Business_Object {get, set}RefValue[RefValPropertyName]
Ну и чем это от датасета будет отличаться? Что городить огород на пустом месте?
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>А зачем свою? Чем не устраивают существующие? Сколько вобще существующих видел?
VD>Если ты о типизированных датасетах,
Нет, я вобще о подобных решениях, о каше, о EJB и т.д.
VD>то они конечно кривоваты. Столько года когда нужно то всего легкую оберточку над отключенным крусором.
Это разве много? Так, мелочь. Ты много не видел. У нас на джаве в свое время код мегабайтами генерился.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это разве много? Так, мелочь. Ты много не видел. У нас на джаве в свое время код мегабайтами генерился.
Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было. Кстати, производительность турда от этого вряд ли повысится. Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях. По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Самый большой прикол со всеми этими обертками заключается в том, что работать нужно со множествами (ну таблицами/списками если по рабочекрестьянски выражаться), а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB). Вот в ООСУБД другое дело. Там и запросы вс6 в терминах ОО. И хранение соотвествующее. Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
... << RSDN@Home 1.0 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
Здравствуйте, VladD2, Вы писали:
VD>Ну и зачем? Там делов то... обернуть датасет чтобы из кода работать удобнее было.
Ага, а еще чтобы ко всем отношениям коллекции были, а еще чтобы это чудо сериализоваться умело. Ты посмотри код, нет там ничего лишнего, все по делу.
VD>Кстати, производительность турда от этого вряд ли повысится.
Не Влад, повышается очень сильно, проверено на практике.
VD>Я бы делал больший упор на визуализацию. 90% работы с БД можно визуально делать. Там же жесткие алгоритмы. А логику можно на сервере обрабатывать. Презинтационную на событиях.
А по хорошему презентационной логики программист вобще почти не должен писать.
VD>По мне так выбрал РСУБД так и работай в ее терминах. Хочешь объеты в БД, то и выбирай ООБД или на худой конец нечно вроде хмл-я (то тут свои проблемы).
Это уже топкая область, тут никаких решений вроде делай так и никак иначе нет.
VD> а все эти обертки или вообще упускают этот вопрос или становятся крайне не эффективными (как EJB).
Да, пожалуй главный недостаток. Но сами датасеты тоже самое — никаких групповых операций они не делают.
VD> Жаль только что на рынке ООСУБД нет пока нет явного лидера вроде МС или Оракла.
Жаль. Но я бы удовлетворился хорошей XML БД, ее до уровня ООБД отмапить несложно. Вот только МС все нас завтраками кормит, а сам пока предлагает только какие то нелепые примочки.
