Строго типизированная DataRow - доступ к полям через прокси?
Строго типизированная DataRow - доступ к полям через прокси?
Не представляю как слепить требуемое.
Имеется.
Достаточно неудобный расчет и желание его порезать на более-менее понимаемые куски.
Расчет делается на базе DataTable, построчно считаются нужные цифирьки.
Для понимабельности кода доступ к блокам полей был написан через прокси.
Прокси - простые - к именам полей добавляется префикс/суффикс и получается доступ
к полю относящемуся к прокси.
Чтобы работало более-менее быстро - строго типизированная строка создавалась один
раз, в ее конструкторе создавались нужные прокси, а в процессе - заменялась фактическая
строка данных.
Все работало пока прокси-классы были внутренними классами строго типизированной
строки.
Требуется: вынести прокси-классы в отдельные дллки.
Туда же, в отдельные дллки, уже ушли процедуры расчетов и списки
используемых полей... и оно все еще продолжает работать.
А вот как вынести туда код прокси-классов и не потерять в скорости - не вижу.
У кого-нибудь требовалось подобное? Как решали?
Ну, во-первых, у меня нет другой возможности кроме как апгрейдить то что есть. Хоть бы это на части разобрать - до сих пор еще не все прозрачно.
Во-вторых - вопросик, как таковой, не привязан к Систем.Дата. Вопросик-то - Как вынести иннер класс во внешнюю библиотеку без потери производительности. Вроде получается.
Правда сейчас выплыло еще одно "маленькое проблемо" - прокси из кода Я вынес, лежат в дллках, грузятся в динамике - тут проблем нет.
Уперся в то, что мне надо привязать неизвестные прокси к переменным, которые предполагают известность прокси.
Т.е. если у меня есть переменная ТРовПрохи Бмц. То мне надо присвоить ей именно ТБмцПрохи, но этот прохи лежит в библиотеке на которую нет ссылки в прoекте.
И таких у меня с пока еще с пару десятков... с тенденцией к росту количества...
Вот сижу и думаю - как делать эту кроссировку...
У вас бизнес логика реализована на уровне хранения информации.
-----
У меня все еще хуже - ВБ6-лике - управление контролами в смеси с логикой и синтезом СКЛ...
Ну и не код обрабатывает данные, а данные управляют кодом.
Все плохо - Я - знаю.
Допустимо в небольших приложениях/прототипах, но не более.
-----
угу... у меня - немного - всего 2 Гб кода...
Возьмите какой-то ORM
-----
У меня структура таблицы - динамическая. Т.е. создается и модифицируется во время выполнения.
Ну и чем мне тут поможет ОРМ? Тем более, что вопросов загрузки/выгрузки данных Я не ставлю.
Если этого мало - у меня старый - 8.1 и 10.2 Оракле с переходом на какой-то Постгрее...
Извините, я с трудом понимаю, то что вы написали.
Если у вас есть конкретный вопрос, то попытайтесь сформулировать его, чтобы вас поняли. По возможности в краткой форме. Не нужно добавлять в вопрос воду, которая не несёт информационной нагрузки.
Заранее спасибо.
-----
Перевод:
Как получить доступ к переменным outer class в c#?
Точнее - как обойти ограничение на отсутствие такой возможности?
Но вот какая штука - когда вопрос уже сведен к приведенному виду - ответ уже не нужен - он уже есть.
Kак сохранить производительность при выносе inner class во внешнюю дллку, не линкованную к проекту?
Как привязать нужные прокси классы из внешних дллок к соответствующим переменны?
До этого Я пока не додумался.
И сформулировать это как-либо внятно - не могу.
Потому как получается что надо привязывать инстансе некоторого типа (по имени типа!) к переменной с некоторым именем (по имени переменной!).
При том что имя типа инстанса станет известно только в ран-тайме и переменной под него может и не быть.
Сильно поднапрягшись и закопавшись глубоко в Reflection, Я может быть напишу работающий код... но работать он будет медленно.
Вот сижу и думаю как тут быть?
Пока йaсно одно - прокси остануться в дллках.
Т.е. если у меня есть переменная ТРовПрохи Бмц. То мне надо присвоить ей именно ТБмцПрохи, но этот прохи лежит в библиотеке на которую нет ссылки в прoекте.
если я правильно понял, то у тебя есть некий класс в сборке, скажем SomeProxyCollection.dll
public class TBmcProxy : TRawProxy { ... }
и где-то еще есть другой класс, в сборке MyCoolApp.dll:
public class SomeClass { public TRawProxy Bmc { get; private set; } ... }
и тебе надо сделать так, чтобы при создании инстанции SomeClass у тебя переменная Bmc инициализировалась инстанцией TBmcProxy?
Если да, то тебе помугут атрибуты :)
Тогда твой класс будет выглядеть так:
public class SomeClass { [ProxyFinder(AssemblyName = "SomeProxyCollection.dll", Type = typeof(TBmcProxy))] public TRawProxy Bmc { get; private set; } ... }
В контсрукторе просто просмотришь все проперти, которые помечены атрибутом ProxyFinder и проинициализируешь все что надо. Работать будет быстро :)
[ProxyFinder(AssemblyName = "SomeProxyCollection.dll", Type = typeof(TBmcProxy))]
Все хорошо, но...
SomeProxyCollection.dll - будет известно только в ран-тайме - бо, их 20 штук и все что я об них знаю - они лежат в своей папочке.
TBmcProxy - будет известно только после загрузки ассембли SomeProxyCollection.dll
Просто Я не могу ползать по коду и что-то чинить в десятке мест каждый раз как добавят что-то новое - Я могу написать это новое, скинуть его в папку и... все - дальше должно работать без изменений.
Если да, то тебе помугут атрибуты :)
-----
Хорошо бы, но...
Чтобы это работало в атрибут надо во время компиляции как-то передать информацию об TBmcProxy.
А Я как раз пытаюсь избежать связки между тем где он используется и тем где он хранится.
И если это неизбежно - предпочту иметь фабрику прокси дающую подходящий прокси по ключу, а не через атрибут.
По крайней мере это будет ОДНО место для ремонта, но ДВА разных определения ключей...
DI - это хорошо.
Читаем кого-нибудь умного... ну скажем Симана...
Там у него написано - анализируем состав параметров конструктора и ищем подходящий...
Возникает вопрос - как найти ПОДХОДЯЩИЙ конструктор при принципиально переменном числе и типах параметров, которые не известны на время трансляциi?
На данный вопрос у Марка как-то ответа не находится.
Или ты таки хотел сказать - Attached Properties? Там - да, может быть. Не пробовал, надо тестить...
Но вот какая штука - когда вопрос уже сведен к приведенному виду - ответ уже не нужен - он уже есть
Правильно поставленный вопрос содержит 50% ответа. Кашпировских тут нет и вытигявать по крупицам из вас то, что вы должы сделать сами, никто не будет.
Kак сохранить производительность при выносе inner class во внешнюю дллку, не линкованную к проекту?
У вас есть замеры профайлера или это вопрос от балды? Premature optimization is the root of all evil.
Мне вот так кажется, что придется полностью отказаться от попыток что-либо "вживить" в строго типизированную строку.
Т.е. оставить ее "как есть" - с доступом к известным полям и всей базовой функциональностью, и делать что-то типа Ехтендед Метходс для каждого отдельного расчета.
Дополнительные накладные расходы будут вроде только на доступ к агрегированной ДатаРов...