Сижу и ломаю голову как упростить себе житие...
Ситуация такая.
Согласно выработанному стандантарту кодинга на одну таблицу в базе данных создается один бизнес-объект.
Разумеется этот бизнес-объект содержит переменные под все поля базы, служебную информацию и базовые методы.
Помимо этого, прямой доступ к переменным перекрыт и для доступа используются проперти.
Все хорошо, все отработано и генерируется без проблем.
Проблемы начинаются когда надо написать код, который должен использовать бизнес-объект которыей еще не сгенерен.
Базовые методы - Save() и Load() - можно выделить в отдельный интерфейс. С этим проблем нет.
Вопрос в том, что делать с пропертями. Каждый бизнес-объект имеет свой набор пропертей. Описать весь набор в виде отдельного интерфейса - затратно, проще сгенерировать бизнес-объект, но по условию того над чем Я ломаю голову его сгенерировать нельзя, надо обойтись без генерации и без большой писанины.
Вот и сижу и думаю как перестроить бизнес-объект, чтобы получить доступ к пропертям, которых нет...

а как же можно использовать обэкт который еше не сгенерен?

А доступ к несгенерённым бизнес-объектам через рефлексию осуществляется? И какой .Net используется?
В .Net 2.0 вроде бы можно в рантайме добавять объектам поля/свойства/... . Сам не делал, просто, поинтересовался однажды о существовании возможности.

а как же можно использовать обэкт который еше не сгенерен?
-----
Объект использовать разумеется нельзя, но писать код, допустим - относительно определенного интерфейса, можно без проблем.
Суть проблемы - описание/база уже существует, но объекты еще не генерированы, а кодеры должны писать код в соответсвии с заданиями. Задания - примитивно простые - умножить значение проперти А на коэффциент (тоже проперть, но другого объекта) В. Место, где они должны это делать - тоже известно. Проблема только в том, что нет объектов.

И какой .Net используется?
------
От 1.0 до 3.х+
можно в рантайме добавять объектам поля/свойства
------
Тоже смотрел. Тоже - весьма поверхностно. Все, что могу сказать - работать будет весьма медленно.
Самое существенное - мне оно не нужно - ко времени сборки объект будет сгенерен и будет содержать
все необходимые поля и проперти.
Я больше думаю в сторону перегрузки operator[](string) с возвратом какого-нибудь обобщенного интерфейса к данным. Правда чем больше думаю, тем больше результат напоминает DataSet и поля. Наверное будет проще перегрузить DataSet, добавив мелочевку...

Ну если имя проперти известно то можно ее через рефлектионс вытянуть..
(int)TypeDescriptor.GetProperties(myObject)["MyIntProperty"].GetValue(myObject);
Насчет медленно, если дескриптор зарание вытаскивать и повторно использовать то очень даже быстро..
DataSet неоптимален с точки зрения памяти - значения он держит как object[] , но в общем случае - тоже хороший вариант.
Но все равно не очень понимаю сценарий - что мешает объекты то сгенерировать, если структура известна ?

Но все равно не очень понимаю сценарий - что мешает объекты то сгенерировать, если структура известна ?
------
Время. Представь себе группу, в которой 97% не имеют достаточных знаний
для самостоятельной генерации или не имеют на своих системах необходимого
софта, а оставшиеся 3% имеют достаточную загрузку помимо таких глупостей,
как генерация БО. И нужно загрузить эти 97% - простое распаралеливание ручного
кодирования, при неполном наборе кода. Желательно, чтобы выполняемая при
этом работа была им по силам и не отличалась от обычного кодинга.
(int)TypeDescriptor.GetProperties(myObject)["MyIntProperty"].GetValue(myObject);
-----
По применяемому стандарту кодирования вторая "точка", точнее - второй уровень
косвенного доступа, не допускается потому и подумываю над упрощением до
myObject["MyProperty"]... при этом в одном контексте мне нужна именно ссылка
на проперть, а в другом - уже значение... еще не придумал чем жертвовать...
скорее всего - ссылкой...
Пропертей с типом int у меня нет. Вообще. Если кому-то удасться такую сделать,
то тип будет TInt, проперть Int и все заломается при трансляции определения
локальной переменной TInt int; :)
если дескриптор зарание вытаскивать и повторно использовать то очень даже быстро..
-----
Это врядли. В коде практически нет мест, где потребуется повторный доступ.
А если он потребовался - значит что то было сделано не правильно - какая-то
функциональность не убрана в классы... Если не следил за другими постами, то
напомню, что у меня каждое поле, начиная с уровня определений полей на
SQL-сервере имеет свой отдельный тип/класс...

Так пусть сами себе проперти и пишут.

Как вариант - да, но код в редакторе будет пестреть красным, что не есть хорошо.

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

А софт трудно скопировать и к нему батч сделать, или хотя бы на выделенный комп посадить (и всем туда доступ по RemoteDesktop или VNC ? ) ?
Или как кастом тул / плагин к Визуал Студио прикрутить?
Если у тебя 29 обезъянок - пусть решают Проблему Всеобщей Доступности Великого Генератора Очень Важных Классов.

Ну количество точек можно произвольно убрать, не в этом дело. Или всю это конструкцию в статическую дженерик тул - функцию засунуть.
Только криво это как то, если ты добровольно заменяешь Compile-time проверку типа (и всякий там интеллисенс) каким то доморощеным ДатаСетом..
Кстати, какова есть причина int не использовать? 8-О

А софт трудно скопировать и к нему батч сделать
-----
Можно, но возникнет куча дополнительных вопросов:
- лицензии - одно рабочее место подорожает на примерно 400-500 евро
- синхронизация - нужно будет отслеживать соответствие объектов имеющейся модели, которая правится "3% умных" по-горячему
и т.п.
Или как кастом тул / плагин к Визуал Студио прикрутить?
-----
Можно. Правда цикл генерации занимает примерно 20-30 минут (зависит от объема генерации) и потери рабочего времени будут немалые...
Только криво это как то, если
------
Если бы Я этого не понимал - не озаботился бы задать этот вопросик. Вопрос в том - как спрямить, оставив обезъянок в комфортной среде разработки...
Кстати, какова есть причина int не использовать? 8-О
------
Причина Есть Регламент! В соответствии с ним в коде встроенные типы использовать запрещено. Разрешено - как поля в классах и локальные переменные в методах. Была пара исключений - строки и переменная итератора цикла, но с доступностью итераторов и это отпало... К тому же каков смысл использования int _int вместо TFlyingObjectCounter flyingObjectCounter, при условии что код TFlyingObjectCounter писать не надо (генерится) и он обладает несколько лучшей функциональностью (применительно к задаче), чем int? :D

Обдумал и решил остановится на следующем варианте.
1. Устанавливаются жесткие правила именования интерфейсов на базе имен таблиц. Сложность исполнения - 2/10.
2. Исполнители пишут сокращенные интерфейсы - только с необходимыми пропертями. Сложность - 2/10.
3. Используя интерфейсы - пишут заданный код. Сложность - 5/10.
4. После генерации используются сгенеренные объекты, имплементирующие полные интерфейсы. Сложность 0/10.
5. Переключнение с рукописных на генерированные интерфейсы - через директивы препроцессора. Сложность - 3/10.
Итого: Наиболее сложный элемент - 3. (5/10) - не требует более высокой квалификации, чем все остальные. Т.е. способные его делать будут в состоянии делать и все остальное.
Какие будут замечание/пожелания?

А может сгенерить упрощенный интерфейс своей примочкой, основа то видимо база.
А голосованием мы тут ничего не решим, на месте всегда виднее.

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

Ну видишь выясняется, что софт ваш, тогда причем лицензии на место. И как то не могу я представить что может занимать 30 минут современного машинного времени. Это же какое количество записей надо обработать. А что ТЗ на модуль нету? Обезъянки только на интерфейс ориентирутся? Но я имел в виду не старое покоцать, а новое написать. Что то типа кодогенератора по своему языку и допустим базы в подмогу.
\\Возможно, что кто-то обдумывал и оценивал что-то подобное
Для начала надо понять что есть и что надо.. Я вот лично никак не могу врубится до конца, может это один я такой тупой?
Пока я понял следующее. Есть какой-то тупой кодегенератор \тупой потому как автоматом не пашет\ который охрененное количество времени генерит какой-то вспомогательный код, который нужен для отладки и написания другого кода. Генератор может запускаться только на определенных машинах и управляется высоквалифированным персоналом.
Требуется найти обходные пути написания другого кода.
Но похоже никто подобным не занимался. Есть просто надежда, что обсужение тебя на вумную мыслю натолкнет.
Были у нас бизнес объекты как плагины к серверу, но не охрененное количество. Может штук 10-20 на сотню таблиц. Не было никаких особых проблем, каждый мог написать плагин, смотри токи на старый, базу и краткое описание. Правда интерфейс был для всех один, различия были в принимаемых командах и отсылаемых данных. Команды свободно генерили обезъянки. Может у Вас обезъянки сильно "тупые"? Или софт какой то "неправильный".

Ну видишь выясняется, что софт ваш, тогда причем лицензии на место.
------
Софт - наш, но не полностью. Был взят за основу RapTier (выбор не мой - Я бы взялся за XSLT или, в крайнем случае, IIS), над ним - наработана дополнительная тяжелая надстройка, выполняющая то, что он не в состоянии. Плюс некоторые сторонние библиотеки компонентов. Вот на RapTier и либы нужны лицензии. В принципе от RapTier'а можно избавиться, но это месяцев 6-8 работы.
Это же какое количество записей надо обработать.
-----
Точно не знаю. :) Счетчики вызовов конструкторов давали восьмизначные значения. Еще могу сказать, что результатом 30 минут работы будет что-то, объемом примерно 250-300 Мб текста.
А что ТЗ на модуль нету?
------
В этом вся прелесть - ТЗ на целевую задачу вообще нету. Есть исходная база, файл желаемой конфигурации приложения (~10-12 Кб) и генератор, строящий полностью работающее приложение. На генератор... хммм... тоже нету. Есть некоторое описание на назначение имплементированных интерфейсов и некоторое описание на идеи. Полных док - нету.
Обезъянки только на интерфейс ориентирутся?
------
Обезъянки, в принципе, вообще могут отсутствовать. Ибо они пишут... считая что объем задачи 200 Мб... от силы 20-25 Кб. Любой из оставшихся 3% может это сделать в течении пары дней. Их подключают только на очень узкую работу - именно то, что было описано выше - Obj1.p1 = Obj2.p3 + Obj4.p6; - в точно определенных местах. Интерфейсом они не занимаются вообще - все генерится, включая всю функциональность.
Но я имел в виду не старое покоцать, а новое написать. Что то типа кодогенератора по своему языку и допустим базы в подмогу.
------
Не выйдет - там много нелинейных преобразований. В свое время Я разложил всю функциональность в строгую иерархию, но потом появились требования, которые без раздельных интерфейсов реализовать было весьма затруднительно. Ну а как перешли полностью на интерфейсы Шеф принял волевое решение - коллапсировал всю иерархию и сбросил всю функциональность в базовые классы... ошибка, конечно, но на то он и Шеф... Но сути это не меняет - вычленить что-нибудь сейчас весьма проблематично, а написать новое - повторить разработку на 80%...
генерит какой-то вспомогательный код
------
Генерится приложение. После генерации оно элементарно компилируется из командной строки и отдается заказчику. Исключение составляют специфические требования заказчика. Например, заказчик говорит, что помимо отображеного грида с данными он хочет видеть дополнительное поле, в котором отображается... хммм... скажем результат суммирования значений определенного поля тех записей на которых он кликал в гриде. Такая задача описывается как операции с пропертями и отдается обезъянкам на кодирование...
Генератор может запускаться только на определенных машинах и управляется высоквалифированным персоналом.
------
Угу... Причины - этот персонал занимается всей моделью приложения - исходной базой и файлом кофигурации, меняет ее по мере поступления требований от заказчика или собственного понимания его требований. Кроме этого он загружен другими задачами, занимающими значительное время и его нельзя/нежелательно произвольно оторвать от этих задач.
Может штук 10-20 на сотню таблиц.
------
Эээ... Это решение для части задачи. Думаю, что указанный объем генерации - 2-3% от задачи. У меня же задача ставилась по-другому - оставить 2-3% для ручного кодирования.
Может у Вас обезъянки сильно "тупые"?
-----
Весьма сильно. Мягко говоря подразумеваются действительно обезъянки - без спец.образования, без опыта в разработках, но владеющие каким-нибудь текстовым редактором. Грубо говоря - берем незагруженного секретаря или техника, в течении пары дней объясняем что и как надо делать, даем рыбу, даем описание задачи - и вперед, переносить с листа в редактор с соопутствующим обрамлением... т.е. кодить... :)
Или софт какой то "неправильный".
------
Тоже возможно. По крайней мере Я не в восторге от того, что используется.
Есть только один плюс - за период с Июня по Сентябрь полтора человека построили и сдали разным заказчикам пять различных приложений, суммарным объемом более 700 таблиц, попутно существенно поменяв концепцию результирующего приложения... т.е. выполнив (оценочно) 25-30 тыс человеко/дней традиционного кодинга/тестинга/сдачи... т.е. 1:200, что есть весьма неплохо...

Ну ты тут целую поэму написал. Но все равно тебя еще надо как в гестапо пытать. В общем получается что- то типа Клариона, только еще монстреозней, как я понял. А чего бы обезъянкам не писать просто темплайты\скрипты, которые при генерации будут просто дополнительно учитываться. А еще лучше пусть сами заказчики их пишут, хотя так иожно больше содрать.
\Счетчики вызовов конструкторов давали восьмизначные значения. Еще могу сказать, что результатом 30 минут работы будет что-то, объемом примерно 250-300 Мб текста.
тяжело такого монстра представить. Но в таком объеме кода разобраться просто невозможно. А если еще на пару сотен таблиц помножить . Но нахрена нужен такой объем для одной таблицы я тоже не могу представить.
\В этом вся прелесть - ТЗ на целевую задачу вообще нету.
Для меня это не прелесть, а катастрофа. Заказчик может тогда менять требования как хочет. А откуда знать тогда, что Obj1.p1 = Obj2.p3 + Obj4.p6;?
\Исключение составляют специфические требования заказчика.
Так это всегда самое главное исключение . По моему мнению, кодогенераторы хороши до тех пор ты в его струе. Чуть в сторону уже проблемы.
\Шеф принял волевое решение
\но на то он и Шеф.
Угу, лучше не спорить.
\Есть только один плюс -
Плюсы то конечно есть, но должно быть и большое количество минусов. Пока я вообще не понимаю как изменения туда вносить. По новому не перегенеришь, потеряешь обезъяний код. Если старые куски переставлять можно забыть чего.

А чего бы обезъянкам не писать просто темплайты\скрипты,
которые при генерации будут просто дополнительно учитываться.
-----
А как им объяснить что именно они должны делать?
Ведь им придется писать код для системы, которая должна продуцировать приложение,
которое еще и в клиент-серверной архитектуре... У меня, хотя Я понимаю как оно должно
работать, от такого голова побаливает...
А еще лучше пусть сами заказчики их пишут, хотя так иожно больше содрать.
-----
Угу... лишь бы платили :)
Но в таком объеме кода разобраться просто невозможно.
------
А его никто и не смотрит. Ну за исключением тех 3%, что могут в нем разобраться.
И этот объем не для одной таблицы - это полная целевая задача - 120-200 таблиц.
Заказчик может тогда менять требования как хочет.
-----
Ну и пусть меняет! В том то и суть - изменения в модели, правка конфига, генерация и... все.
Чуть в сторону уже проблемы.
------
Разумеется. Потому и получается монстровый генератор для покрытия большинства возможных проблем...
По новому не перегенеришь, потеряешь обезъяний код.
-----
Не-а... Обезъяний код остается... для него есть отдельный, непереписываемый уровень...
Если старые куски переставлять можно забыть чего.
------
Там есть такая штука как коде-ижектион - после генерации делается точечная вставка "старых" кусков.

Встретились два рыбака ...