Сижу и ломаю голову как упростить себе житие...
Ситуация такая.
Согласно выработанному стандантарту кодинга на одну таблицу в базе данных создается один бизнес-объект.
Разумеется этот бизнес-объект содержит переменные под все поля базы, служебную информацию и базовые методы.
Помимо этого, прямой доступ к переменным перекрыт и для доступа используются проперти.
Все хорошо, все отработано и генерируется без проблем.
Проблемы начинаются когда надо написать код, который должен использовать бизнес-объект которыей еще не сгенерен.
Базовые методы - 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 таблиц.
Заказчик может тогда менять требования как хочет.
-----
Ну и пусть меняет! В том то и суть - изменения в модели, правка конфига, генерация и... все.
Чуть в сторону уже проблемы.
------
Разумеется. Потому и получается монстровый генератор для покрытия большинства возможных проблем...
По новому не перегенеришь, потеряешь обезъяний код.
-----
Не-а... Обезъяний код остается... для него есть отдельный, непереписываемый уровень...
Если старые куски переставлять можно забыть чего.
------
Там есть такая штука как коде-ижектион - после генерации делается точечная вставка "старых" кусков.

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

\А как им объяснить что именно они должны делать?
А как они сейчас знают что писать? Просто язык может быть другой.
\Ведь им придется писать код для системы
Так они ведь не программисты, все равно хрен чего напишут.
\Не-а... Обезъяний код остается... для него есть отдельный, непереписываемый уровень
Так пусть туда и пишут, нафиг им еще что-то.
\Ну и пусть меняет!
А за что с него деньгу драть? Заказчик не должен догадываться что это просто. Да и по любому надо документировать его требования. Завтра скажет, а мы такого не говорили. Да и просто до тех пор когда в струе идет.
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.

Встретились два рыбака ...
------
Да-да... правда проекты сданы заказчикам...

Так пусть туда и пишут, нафиг им еще что-то.
------
А куда им еще его писать? Все остальное еще отсутствует напрочь... :) Вопрос в том,
как создать/оставить для них более-мение комфортную среду и исключить необходимость
дополнительного контроля.
Так они ведь не программисты, все равно хрен чего напишут.
------
У меня - пишут. Не первый раз и не первый год. Секрет в том, что нужно ставить
выполнимую (ими) задачу (см. начало топика) и объяснять как ее выполнить.
Ну и тупых - отстреливать... :)
Заказчик не должен догадываться что это просто.
-----
Гы? Если ему покажется что это просто он может взять других для сопровождения.
Потом - все одно вернется... ибо дешевле и быстрее никто не сделает.
Да и по любому надо документировать его требования.
-----
Или посылать подальше и работать с другими, стоящими в очереди на необходимый
им и относительно дешевый софт. Осознай - затраты на разработку примерно в 200 раз
ниже стандартных и сроки - еще в 20... Пришел, объяснил что желаешь, через день-два
получил работающий прототип, потестил, сказал что не так и через две недели - полный
релиз...
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.
-----
Не понял смысла.

...как создать/оставить для них более-мение комфортную среду и исключить необходимость дополнительного контроля.
Сам же говорил что самая комфорная среда для них - текстовый редактор. А контролировать в любом случае надо.
А как бы они писали в благоприятном случае?
Написать в редакторе что то типа:
table5.field6 = table2.field3 + table3.field2
любая обезъяна сможет
\У меня - пишут. Не первый раз и не первый год.
А говорил, взял уборшицу на полставки.
\Если ему покажется что это просто он может взять других для сопровождения.
Надо быть либо ненормальным либо в безвыходном положении что бы сгенерированную программу обслуживать без кодогенератора.
\Пришел, объяснил что желаешь, через день-два получил работающий прототип
странно это, обычно больше времени уходит что бы просто выдрать у заказчика нужную форму отчета. И как спроектировать базу на сотню таблиц за день, я тоже не могу представить.
Хотел бы еще глянуть как этот монстр будет пережевывать запрос на тыс 15 человек этак.
-----
\Не понял смысла.
Просто интересно было оценить производительность. Наша система вначале тормозила по черному.

самая комфорная среда для них - текстовый редактор.
А контролировать в любом случае надо.
------
А минимизировать издержки?
А как бы они писали в благоприятном случае?
------
Вот Я и думаю над тем, что им надо дать...
Надо быть либо
------
Вот и Я об том же.
И как спроектировать базу на сотню таблиц за день, я тоже не могу представить.
------
Обезъянками. Правда немного дрессированными. :)
А вообще - сделать базу на сотню таблиц - не проблема. Просто делаешь копи-пасте приблизительно подходящих по размеру кусков скриптов и правишь напильником по месту...
Об одном желею - не успел доделать использование множественных баз в качестве источника. Тогда было бы вообще без проблем - просто ссылаешься на имеющуюся базу и она включается в результирующую модель...
Просто интересно было оценить производительность.
-----
250-300 мег готового кода за 20-30 минут. Есть небольшая экспоненциальная зависимость от количества таблиц, есть возможность ускорить обработку примерно в 10-20 раз... Система - не реентерабельная, но можно запустить несколько задач в паралели... Упрется - в производительность дисковой подсистемы...

Да Вы бы тоже подключались, на троих уже и сообразить можно

\А минимизировать издержки?
в смысле контроля? Может конечно и заказчик проконтроллировать, но это не солидно.
\Вот Я и думаю над тем, что им надо дать
А что ничего еше вообще нету? Как раньше делали- то?
\А вообще - сделать базу на сотню таблиц - не проблема. Просто делаешь копи-пасте...
Ну только если задачи примерно одинаковые. Я помню, мы как-то десяток таблиц больше недели обсуждали как лучше сделать \ну не все время подряд конечно\
Отчеты тоже небось стандартные.
\250-300 мег готового кода за 20-30 минут
производительность не кодегенератора, а готовой программы. Ты правда не учитываешь затраты на разработку кодогенератора и самих кусков кода. Судя по размерам получается просто многократное копирование одних и тех же частей.

в смысле контроля?
------
Разумеется. Например, можно объяснить, что подчеркнутое красным - некорректно. Это несложно и вполне по силам обезъянкам... причем, можно ожидать, что пара объяснений причин появления красноты решит проблему.
А что ничего еше вообще нету? Как раньше делали- то?
------
Да, вообще ничего, кроме каких-то заметок на бумаге...
Ранее использовался более квалифицированный персонал.
Ну только если задачи примерно одинаковые.
------
Покрываемый класс задач - примерно одинаковый. Детали, разумеется, отличаются, много чего можно и копи-пастить с последующей правкой.
мы как-то десяток таблиц больше недели обсуждали как лучше сделать
-----
Бывает. Бывает, что и после этого все идет в мусорник и делается по-новой... как и в любом проекте. Тут плюс - не надо переделывать весь код и стыковки с переделанной частью - просто меняешь и генеришь...
производительность не кодегенератора, а готовой программы.
------
Не слишком отличается от рукописных аналогов. По крайней мере мне регулярно встречается гораздо больше плохо (с точки зрания производительности) написанного кода. Кроме этого, для программиста, - производительность системы это число процессоров в кластере... :)
Дополнительно - производительность, наравне с архитектурой результирующего приложения, это головная боль 3% уменьких и они вполне четко осознают где теряется производительность, когда ею можно жертвовать и как ее поправить...
Ты правда не учитываешь затраты на разработку кодогенератора и самих кусков кода.
------
Учитываю. Это как раз основной момент, почему требуется максимально разгрузить 3% квалифицированного персонала. В частности их работа - получив нестандартные (не укладывающиеся в возможности генератора) требования от заказчиков, оценить их с точки зрения нестандартности и принять решение об способе имплементации - отдать обезъянкам или выполнить модификацию генератора.
Судя по размерам получается просто многократное копирование одних и тех же частей.
------
Близко, но не совсем. Там создаютя уникальные БизнесОбъекты и заданные формы их отображения, учитывающие все заданные связи и ограничения. Разумеется все делается по предопределенным шаблонам, но общий код - убран в базовые классы и либы. Возможно, что там все же есть избыточная, не используемая приложением, функциональность, но было решено, что БизнесОбъекты будет иметь полную функциональность. При желании можно поправить ключи к шаблонам и исключить неиспользуемую функциональность, но будут проблемы... у высокотренированных обезъянок... Да Я и сам не люблю ситуацию, когда берется БО и у него нет какого-то метода, имеющегося в другом аналогичном объекте...

\Разумеется. Например, можно объяснить, что подчеркнутое красным - некорректно.
Ну это только синтаксическая неккорекность, а как ты выловишь что вместо таблицы 1 написали таблица 11? Либо что-то другое синтаксически правильное.
\Ранее использовался более квалифицированный персонал.
Пока я вижу только специализированный редактор, который возможно знает описание модели и базу, для проверки\подсказки.
\Тут плюс
меня больше интересуют минусы. Я бы как заказчик, не брал бы себе кодогенерированный код, попадешь в сильно большую зависимость от производителя как минимум. Хотя причины использования тоже понятны: цена и время.
Кстати, если считать среднюю длину строки в 60 символов, что думаю сильно много,на 300 мб получается около 5 000 000 строк кода. Это много, сильно много для обычного проекта, осюда у меня и мнение о большой избыточности.

а как ты выловишь что вместо таблицы 1 написали таблица 11?
------
А насколько это критично? Пусть _везде_ написано таблица_11... общая замена и нет проблем... Проблема это когда в одном месте таблица_11, в другом таблица_, в третьем лрплрп_паорп...
Пока я вижу только специализированный редактор
-----
Стандартная студия? Конфиги для генератора и база правятся независимо...
Я бы как заказчик, не брал бы себе кодогенерированный код
-----
Да, цена/время... А какова вероятность, что те, кто будут писать без генератора напишут лучший код? Мне очень редко попадается грамотно написанный код. Причем - во всех аспектах - от архитектуры приложения до форматирования текста... Особенно впечатляют долгоживущие проекты - смотришь и видишь пять-десять стилей написания, перемешанных между собой... часто предпочтительнее иметь стандартизованный код, имеющий базовую функциональность и средства ее наращивания. Именно это и делается при генерации.
Это много, сильно много для обычного проекта
-----
Ну давай возьмем обычный проект и посмотрим насколько он будет меньше, при тех же требованиях к результирующей задаче... :) Много меньше не будет. Есть шанс, что будет существенно больше, особенно при низкой квалификации исполнителей.
С другой стороны - код хорошо структурирован и не имеет перекрестных зависимостей - правка/наращивание одной формы/объекта делается без проблем. Если для этого нужно жертвовать генерируемым объемом - значит надо жертвовать нераздумывая - время, время, время... лишняя сотня мегабайт генерированных исходников ничего не значит...

\А насколько это критично? Пусть _везде_ написано таблица_11... общая замена и нет проблем...
Ты же хотед без контроля, а кто будет заменять и главное знать, что надо заменить.
\Стандартная студия?
Не обязательно. Я исхожу из того что программировать на шарпе онм вообще не должны, просто пишут какой-то скрипт. А уж использовать его дело тех 3 процентов.
\А какова вероятность, что те, кто будут писать без генератора напишут лучший код?
Незнаю, но он не будет машино-дурной.
\Ну давай возьмем обычный проект и посмотрим насколько он будет меньше, при тех же требованиях к результирующей задаче...
без примерной задачи тяжело сказать. Просто мне кажется, что миллионном строк уже можно покрыть довольно сложный проект. Нверняка ваши темплайты не занимают столько места и объем получается просто многократным использованием одинаковых темплейтов.
\Есть шанс, что будет существенно больше, особенно при низкой квалификации исполнителей.
Такие исполнители просто не напишут работающий проект такого объема. Уже сотню тысяч строк кода тяжело держать под полным контролем, что говорить о более чем миллионном коде.

Ты же хотед без контроля, а кто будет заменять и главное знать, что надо заменить.
------
Хотел и хочу. При наличии ошибок при трансляции вывалится отсутствие типа и нужная обезъянка получит указание на предмет посмотреть свой код на несоответствие и разъяснение, если посмотреть не сработает. Важно, чтобы обезъянка не была тупой и была способна повторить это самостоятельно при аналогичных проблемах.
Я исхожу из того что программировать на шарпе онм вообще не должны
------
Ну Я все же ожидаю от них немного большего - класс по шаблону (на 80% построенный простым визардом) и определение используемых интерфейсов.
Незнаю, но он не будет машино-дурной.
------
Не уверен. По крайней мере регулярно имею дело с гораздо худшими образцами. Последний из них - один из проектиков на VB6 - практически единичная форма (хотя их реально более двух десятков, но вся операционистика в этой одной) объемом около 250 Кб... может это и не машино-дурной код, написанный вполне квалифицированными спецами, но чтобы понять что и как там делается нужен не один месяц...
Просто мне кажется, что миллионном строк уже можно покрыть довольно сложный проект.
-----
Разумеется. 150-200+ таблиц - это уже сам по себе сложный проект. Даже если не требовать чего-то специфического в функциональности, то просто набор форм для построчного и табличного показа/редактирования данных уже даст весьма-весьма приличный объем...
Нверняка ваши темплайты не занимают столько места
-----
Разумеется не занимают. На практике шаблон, а шаблоны используются активные, т.е. продуцируемый код совпадает только в случае совпадения всех исходных условий, в противном случае код будет похожий, но различающийся, может быть в 5-10 раз меньше или больше единичного продуцируемого файла. Но файлов продуцируется много.
Такие исполнители просто не напишут работающий проект такого объема.
------
Не то, что такие исполнители, но даже набрав высококвалифицированных спецов все одно не сделать в приемлемые сроки. Ну либо они сделают что-то похожее, но за другое время. Поэтому и ставилась задача - построить не куски, из которых надо что-то собирать, а полностью работающее приложение, в котором можно производить необходимые модификации, необращая внимание на то, как реализуется остальное.

У вас такая идиллия, как можно?

А что есть желание подпортить?
Я помню Вы кошек недолюбливается, но втроем думаю будет веселее.

\Хотел и хочу. При наличии ошибок при трансляции..
Не думаю, что получится. Контроль всегда полезен. Вот мы сейчас на работе модулями поменялись и тестируем их. Занятная вещь получается уже и на свой модуль по другому смотришь, хотя большую часть времени занимает борьба с программой тестирования, сильно глякавая.
А какой тебе толк, что не будет ошибок синтаксиса? Все равно может быть неправильно. Дай им редактор где просто нельзя допустить синтаксическую ошибку, ну типа квадратики стрелочками соединять.
\Ну Я все же ожидаю от них немного большего - класс по шаблону
А зачем тебе такое добро? Пусть пишут 20%, а ты из этого сгенеришь класс который нужен.
\Не уверен. По крайней мере регулярно имею дело с гораздо худшими образцами.
Вполне возможно, хороший проект создать не просто. Просто я имею в виду не конкретно твой проект, а кодогенерированные проекты, где один шаблон погоняет другим. Хотя конечно это еще вопрос, что хуже "робот" или "спагетти".
\то просто набор форм для построчного и табличного показа/редактирования данных уже даст весьма-весьма приличный объем...
совсем не обязательно достаточно, иметь базовые формы и их чуть модифицировать. Да и формы можно генерить по заранее заданным данным. То бишь нужно просто хорошо сделать базовые элементы.
\Не то, что такие исполнители, но даже набрав высококвалифицированных спецов все одно не сделать в приемлемые сроки.
Во первых, на проект уже было затрачено достаточное время. Во вторых, все задачи кодогенератом не покроешь или иначе есть класс задач который оптимальным образом подходит под кодогенератор. Так что все равно будут ручные проекты.

А какой тебе толк, что не будет ошибок синтаксиса?
-----
На этом уровне, если нет синтаксических ошибок, то есть 98% вероятность корректности.
Все равно может быть неправильно. Дай им редактор где просто нельзя допустить синтаксическую ошибку, ну типа квадратики стрелочками соединять.
-----
Дал бы. Но готового у меня нету. Была когда-то малоизвестная разработка - IAF (Internet Application Freimwork) - там что-то похожее делали. Но даже там соединение давало лишь интерфейс, который надо было имплементировать руками... А квадратики... квадратики, так как нет сгенеренных классов или других данных, надо будет именовать... в ручную... в именовании будут ошибки... Вообщем, проще отстреливать непригодных обезъян... :)
А зачем тебе такое добро? Пусть пишут 20%, а ты из этого сгенеришь класс который нужен.
-----
Зачем - Я раньше описывал - именно для этого выделен отдельный уровень имплементации.
В принципе, те 3% умненьких могут это сделать на уровне который задействован для коде-инжектион. Избытка писанины там не будет, но при квалификации ниже средней там делать нечего - там ошибаются даже те, кто им непосредственно занимается. По крайней мере Я бы туда полез только в безвыходной ситуации - когда занимавшийся этим местом человек уволился. И что тогда будут делать обезъянки? :)
Хотя конечно это еще вопрос, что хуже "робот" или "спагетти".
-----
У меня есть возможность переработать неустраивающий шаблон... вплоть до полной замены...
но ни у кого нет возможности переработать Спагетти, неизвестно что и как делающее...
и их чуть модифицировать
-----
Ты упускаешь один момент. Как раз самого первого поста. По принятой архитектуре БО должен иметь проперти, соответствующие полям базы и дополнительным полям, определенным в конфигурации. Можно было делать по-другому - иметь какую-то базовую информацию, используя которую в динамике генерировать и связывавать контролы форм с источниками данных, но это - другая архитектура, с другими ограничениями (в частности - проблемно будет добавлять новые типы контролов). Возможно, что когда-нибудь архитектура сменится (или ее уже поменяли) и тогда будет продуцироваться другой объем кода, но не сейчас. Сейчас - так как есть...
Так что все равно будут ручные проекты.
-----
Разумеется. Просто зачем руками писать то, что может быть построено автоматом? :)

\На этом уровне, если нет синтаксических ошибок, то есть 98% вероятность корректности.
Можно видимо студию просто как редактор пользовать, но классы писать то твоему заданию не к чему, классов то нету. А нормальный синтаксис проверить не так уж и сложно.
\Дал бы. Но готового у меня нету
ну так пусть кто-то сделает
\А квадратики... квадратики, так как нет сгенеренных классов или других данных, надо будет именовать... в ручную
так у тебя же модель есть, чего бы ее не приспособить?
\Зачем - Я раньше описывал - именно для этого выделен отдельный уровень имплементации.
Только из-за того, что как ты раньше описывал этой имплентации у тебя нету. Из-за этого то весь сыр бор.
\И что тогда будут делать обезъянки? :)
писать код, только в другом формате.
\У меня есть возможность переработать неустраивающий шаблон... вплоть до полной замены...
А у пользователя твоей программы есть такая возможность?
\По принятой архитектуре БО должен иметь проперти, соответствующие полям базы и дополнительным полям
Вообще-то я сторонник "раздельной архитектуры". БО имеет набор операций и аттрибутов нужных мне, а база, как "удобно базе".
Ну типа, если М:Н отношение в базе нафиг мне три БО.
Хотя реадкторы БД работают примерно по твоему принципу
\...будет продуцироваться другой объем кода, но не сейчас. Сейчас - так как ест
Ну я не требую этого сделать немедленно.
Просто не могу понять откуда столько кода и для чего. Даже уверен, что в сушествующих "ручных" аналогах кода меньше на порядок.
\Просто зачем руками писать то, что может быть построено автоматом?
Хотя бы затем, что бы не писать этот автомат.
Хотя иногда бывает надо. Мне пришлось недавно тоже согрешить. Надо было из одних структур генерить другие. Ну руками заломало, да и ошибится легко.

Воркуйте уж дальше.
Кошек я люблю :) http://simple.strana.de/pusia2.jpg :'-(

классов то нету.
-----
Для обезъянок как раз выделен отдельный уровень в иерархии классов.
Проблема том, что базовые классы этого уровня еще не сгенерены...
ну так пусть кто-то сделает
-----
Мечтаю об таком уже лет 7-8-мь. Правда несколько в другой постановке - для редактирования графов. Даже написал прототип между работами... а вот до ума довести - времени не хватает. :(
так у тебя же модель есть, чего бы ее не приспособить?
-----
Если Я ее приспособлю - придется заюзать генератор. Из-за нелинейных преобразований... там, по условиям, любая информация из базы используется только как источник и может быть полностью переопределена в конфигураторе. Типа есть в базе поле MoyoPole, а выход может быть переопределен как TvoePole... при желании - отдельное наименование в контексте каждой таблицы/базы/хоста/сети & etc...
Только из-за того, что как ты раньше описывал этой имплентации у тебя нету.
------
У меня нету базового уровня. Потому обезъянкам предлагается сделать это ручками.
писать код, только в другом формате.
-----
Не уверен, что смогу обучить и получить адекватный результат.
А у пользователя твоей программы есть такая возможность?
------
У пользователей генератора? Да, конечно... внести изменения - не сложно - шаблоны можно редатировать хоть в Нотепаде... правда нужно понимать, что будет на выходе, а это уже не Нотепад.
БО имеет набор операций и аттрибутов нужных мне, а база, как "удобно базе".
-----
Да почти тоже самое. Только в виду того, что генерятся не только БО, а целиком приложение, база будет не такая, какая она хочет быть, а такая, какая она нужна приложению - вычищенная от глупостей туповатого ДБА.
Ну типа, если М:Н отношение в базе нафиг мне три БО.
-----
Так и мне не надо. Но вот подстановочку на место ключа - надо даже для Н:М... и возможность сохранить установленные связи - тоже не помешает... у ручками писать их не хочется... вот напишу в имени таблички префикс "map" и пусть генератор разбирается откуда и куда там сделано М:Н и реверсивное ли оно... И если он решит, что там надо не три объекта, а четыре или пять - пусть делает - Я ведь даже смотреть не буду сколько их там, при условии, что они функционируют корректно...
Просто не могу понять откуда столько кода и для чего.
-----
Покрытие для полной задачи. Типа есть 10 операций, допустимых на форме, и из них реально юзеру разрешаются три. Код поддержки остальных 7-ми - остается, ибо есть 90% уверенность, что юзер скажет что они ему нужны... тогда без регенерации поменяем битик в базе и у него будет кнопочка для того, что он хочет...
Да, забываю - строится не WinApp, а WebApp - формы довольно объемные...
Хотя бы затем, что бы не писать этот автомат.
Ну руками заломало, да и ошибится легко.
-----
Для того и есть автомат. Тут как-то надо было извратится - написать что-то, аналогов чему еще не делали... решилось так - база, пара таблиц, пара вьюшек, генерация и с десяток строк кода поверх генерированного кода... бос был доволен, хотя сказал что он не совсем понимает как именно это сделано... с технологической точки зрения... заказчик тоже... ну а ручками бы Я провозился несколько дней... Так что генерируемый код не есть большое зло... при доступности генератора.

Кошек я люблю :)
-----
Еще бы ты их готовить научился... ;-)

Вот какой вредный, на троих не хочет сообразить
Должен я за всех отдуваться,так и алкашом стать мона

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

\Для обезъянок как раз выделен отдельный уровень в иерархии классов.
\Проблема том, что базовые классы этого уровня еще не сгенерены...
Это я понял уже давно. Поэтому и говорю, что не надо им программировать на шарпе тогда и базовые классы не понадобятся.
\Правда несколько в другой постановке - для редактирования графов.
Я иногда erwin использую не по назначению, но и visio подтянулось. Можно было взять какой-то open soursik редактор и подработать.
\Если Я ее приспособлю - придется заюзать генератор. Из-за нелинейных преобразований..
\Типа есть в базе поле MoyoPole, а выход может быть переопределен как TvoePole.
Так а проблема, главное чтобы привязка была, а переименовывать одно поле или два проблем не должно быть.
\Не уверен, что смогу обучить и получить адекватный результат.
Ну если на щарпе научил, то попроще тоже должно получится.
\У пользователей генератора? Да, конечно
Хочешь сказать что даете заказчикам генератор.
Не знаю, у меня после Досовского еще Клариона аллергия на кодогенераторы.
\Так и мне не надо.
Просто помню ты говорил, что один к одному требуется.
\Да, забываю - строится не WinApp, а WebApp
Про WebApp не знаю. У нас тоже был доступ через веб, но свой http server. Были шаблоны страниц которые заполнялись данными через плагины.

Поэтому и говорю, что не надо им программировать на шарпе тогда и базовые классы не понадобятся.
------
А стимулировать как? Тупое кодирование, без понимания что и как и без шансов понять что и почему? Надолго этим не занять, очень быстро надоест, снизится внимательность и полезут ошибки... а вот если пишет что-то похожее на программу и получая разъяснения - растет, видит на тестинге как работает... тут гляди и в ВУЗ попросится...
Хотя некоторым, не умеющим готовить кошек, такое не угрожает... :)
Я иногда erwin использую не по назначению, но и visio подтянулось.
-----
Ну тогда можно и EM сиквеловский дать и возможность генерить... только объяснять больно долго, а проект надо сдавать... плановый срок на начальном этапе - две недели, по мере приобретения навыков - до недели... Вообщем что именно они должны делать - понятно, осталось обеспечить более-мение приемлемо-комфортную среду.
Просто помню ты говорил, что один к одному требуется.
-----
Я говорил, что в большинстве случаев делается 1-к-1. А требуется - чтобы работало... :) и если проще сделать 2, 3, ... 10 - то столько и надо делать.

смотри не накаркай, а то получим
-----
Нее, не получим... Бо, Муррка, при желании, проживет даже на Коболе с Фортраном... пусть даже с асмовскими делишисами...

Фу, я такую дрянь не ем ;)

\А стимулировать как?
Ну вот, а вначале так мало хотел.
Но за пару недель не сделать вместе с проектом. Проще будет сгерерить, видимо.

\проживет даже на Коболе с Фортраном
Чур тебя. Еще этих динозавров не было.

Ну вот началось
Главное не есть, а хорошо приготовить.

Тот, кто не умеет ценить хорошую еду, не в состоянии ее приготовить :)

Думаю, что тот кто может оценить, может тоже не уметь готовить.

При чем тут это?

Типа ответ на:
"Тот, кто не умеет ценить хорошую еду, не в состоянии ее приготовить"

Ну а смысл-то?

Смысла не больше чем написано, я ведь не Эзоп.
А какой должен быть смысл?

Начнем сначала: ты писал, что главное не есть, а хорошо приготовить. Я ответил, что тот, кто не ценит вкус, хорошо приготовить не сможет, то есть, есть все-таки надо :) А твое последнее замечание уже не пришей кобыле хвост, да и никто с этим спорить не будет, я думаю.

Зачем искать смысл,там где его не нужно его искать.
Я высказал свое мнение, правильное оно или неправильное, нужное или не нужное мне сейчас уже по барабану. Доказывать что-то или спорить я не собираюсь. У тебя есть свое мнение, ну и хорошо.
Давай, лучше выпьем за то, чтобы у каждого было свое мнение
Хотя, я начинаю понимать отчего вы с муркой деретесь.

Хотя, я начинаю понимать отчего вы с муркой деретесь.
-----
Мы таки не деремсИ... Просто иногда, как и положено Котейке, я оставляю на нем скратчи... :)

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

C ЗИ мы деремся по одной простой причине: никто не любит трепачей :)

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

Я знаком с его писаниной несколько дольше тебя, так что позволь тебя уверить, что образ совершенно верный ;)

:-)

несколько дольше
------
Стоило бы поискать не во времени, а в датчиках и процессоре... :)
Процессор, как говорят, весьма-весьма слабенький... :(((

Самое интересное, что он че-то пыжится, пишет, а я его писанину все равно не вижу :)