sopromat webusДля обработки хранимых процедур пишется огоромное количество монотонного кода, разница в нем только кол-во параметров и название процедур.Имхо, это причина Ваших ощущений.
В красиво спроектированной системе кол-во повторяющегося кода стремится к нулю.

Программист-ЛюбительЕсть хорошая книжка на эту тему "Архитектура корпоративных программных приложений" Мартин Фаулер.

Если представить что сейчас 50-ые годы и этот стон вопиющего в пустыне раздался не по поводу разработки "корпоративных" приложений, а по поводу вообще програмирования базовой логики типа циклов, переходов типа If, Switch а также блоков повтоярющегося кода, а все программируют блин в машиных кодах и на перфокартах, и тоже вот такой вот дядька спец своего времени по перфокартам говорит: оооо... есть хорошая книжка Марка Фалермана, называется: "Новейшие методы выкладывания перфокарт стопками".
Чесс слово тоже самое....
Я понимаю были времена машинных кодов, потом появился С, который являет собой тооненькую прослойку над машинными кодами, а затем революционный С++. Эти средства решили технологические проблемы того времени, когда программы писались годами коллективами специалистов и это было очень дорого удовольствие.
Но с тех пор (с 70-ых годов) ведь ничего НОВОГО создано не было. Java, Pascal, C# - суть упрощения языка С++, но принципиально нового ничего внесено не было.
Между тем, если разобраться язык С++(C#, pascal, Java, and a lot of frameworks), как инструмент программирования позволяет более ЛЕГКО, НЕПРОТИВОРЕЧИВО и удобно писать программы, облегчая ТОЛЬКО уровень описания процедур алгоритмов низкого уровня (базовая процедурная логика (переходы, циклы, вычисления).
Классы языка - еще один способ инкапсуляции ПРОЦЕДУР. Даже свойства - это процедуры (функции если угодно).
Однако до сих пор НИЧЕГО не создано для атоматизации следующего уровня, ради которого эти функции и прочая машинная логика объединяются - приложения как логически целостное, непротиворечивое и ЦЕЛЕСООБРАЗНОЕ творенип предназначеное для решения определенного круга задач.
Вот когда бужет такое средство, то и соответсвующие ощущения пропадут.

Качественно разрабатывать можно быстро и медленно. Располагая вечностью, можно разрабатывать практически на любом средстве - начиная от машинных кодов – и, притом, очень качественно, исключая повторы, создавая стройную и красивую систему и т.п..
Практически для любого примера «ужасного кода» на любом языке можно привести контр аргументы в виде упоминания о «best practice» или начать говорить о разумном проектировании и неких принципах, которых должен придерживаться разработчик. Главным виновником, как правило, оказывается «человеческий фактор». По сути, решением проблемы качественной разработка приложений является призыв: «Хочешь качественной разработки – разрабатывай качественно. Никто тебе не мешает».

Однако, в любом труде хочется (приходится) иметь инструмент, который часть работы сделает за тебя или позволит серьезно уменьшить твои усилия.

В некотором приближении разработкой приложений можно считать ввод информации в систему о правилах обработки информации. Разработка программ – это процесс передачи оператором данных в систему о том, как, грубо говоря, должны оборачиваться в ней байты и биты в зависимости от возможных будущих воздействий на неё других людей или физических процессов.
Рассматривая процесс программирования в таком «ракурсе», можно вынести основные принципы сокращения усилий программиста: информация, вводимая в систему программистом (во время процесса программирования) должна быть необходимой и достаточной для её функционирования. Иными словами она не должна как минимум повторяться. А во-вторых, не должно происходить её потерь.

«Подразумевая» некий автоматизируемый «бизнес-процесс», программист вносит данные в систему («делает программу») на всех её уровнях:
1) Когда проектирует структуру БД
2) Когда проектирует интерфейс
3) Когда создает бизнес логику
4) Когда делает запросы для отчетов и сами формы отчетов

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

Между тем, каждый из названных слоев повторяет, дублирует и частично перекрывает данные-основания любого другого слоя. В случае создания взаимных противоречий в функционировании слоев мы имеем случай потери информации вследствие её неопределенности, бесполезности и даже вредоносности. Так, например: при проектировании БД уже создается знание о системе, которое может быть использовано при проектировании интерфейса и бизнес логики. Бизнес логика оказывает влияние на, опять же, интерфейс и на систему отчетности и наоборот. И так далее.

Все современные Фреймворки, языки программирования категории ООП, а также языки запросов напоминают слепых кротов способных ощупать семантическое пространство приложения на расстоянии коротеньких лапок своих операторов. А лапки эти очень коротки. И только «сильная, уверенная и очень трудолюбивая рука» команды проектировщиков, постановщиков, тестировщиков и программистов способна провести этих «уродцев» сквозь сложноустроенное пространство семантики законченного приложения.
Принципиальным решением указанных проблем было бы создание инструмента разработчика, логически согласованно автоматизирующего создание отдельных компонентов системы, на основании общих метаданных, описываемых в терминах автоматизируемой предметной области.

Выше я сказал том, что знания, закладываемые в систему, взаимно перекрываются или оказывают взаимное влияние. Это взаимное влияние является системой семантических связей. Для задач различного класса структура и содержание семантических связей отличаются.
Мы можем спроектировать инструмент с неким предзаданным семантическим пространством, но он будет способен решать только узкий круг задач и только одним известным шаблонным способом.
Мы можем спроектировать инструмент с изменяемым (программируемым) семантическим пространством или, иначе говоря, с изменяемой моделью приложения. Такой инструмент, хотя и ограниченный предлагаемой «моделью моделей» обладал бы уже некой универсальностью и возможностью творить, а не кроить однообразные программки по шаблону.

Техническая реализация
Если кто-то согласен или кто-то понял сказанное….
Какие мысли есть по технической реализации??

Извиняюсь за многа букаф.

Е.В.С...... Опыта мало, возраста мало; желаний, энтузиазма и амбиций дохе.. много короче... сильно ногами не бейте если что не так... просто мысли вслух...
Alexsalog
Между тем, каждый из названных слоев повторяет, дублирует и частично перекрывает данные-основания любого другого слоя.
Не совсем понял, если не затруднит то в реальных/простых примерах по возможности..

Например вам нужно сделать ввод документов типа счетов.
Вы представляете себе что это такое. Вы знаете, что у документа есть шапка и есть спецификация. в шапке такие то поля приотм некоторые являются ссылками на справочники.
В спецификации нечто подобное. Это назовем : данные-основания.

Теперь, вы делаете интерфейс. Как вы его делаете? Вы непременно будете учитывать в проектировании интерфейса подобноо отношение частей документа. Это окажет влияние на дизайн документа.
Далее вы проректируете базу данных. Опять же вы учитываете названные выше ОДНИ И ТЕ ЖЕ исходные данные, но только в применении к таблицам.
Далее вы пишете запросы, и опять в секции where вы заново указываете уже набившие оскомину отношения между данными но только в интепретации к SQL языку.
А есть еще справочники - и для них цикл разработки целиком повторяется. Все тоже самое повторенное несколько раз на разных уровнях и в разной форме.
Это и создает ощущение нудности и постоянный страх ошибки. Потому что например при написани SQL запроса ничего не стоит связать шапку документа с Id контрагента по полю предназначеному для связывания со спецификацией. И получить полную чушь. И СУБД это проглотит и не поперхнется.
Это я и назваю "слепотой" инструментов данных современному разработчику. Им (инструментам) своершенно плевать на законченность и логичность конечного приложния. Они на все согласны и им все равно что делать. Такая вот метафора.

DVE1.Для быстрой разработки клиент сервеного приложения с большим количествои форм и табличек полагаю нужно использовать отличные от C#.NET инструменты, например J2EE, Oracle Forms, Delphi

2.Во избежание переписывания однофункционального кода разными программистами:
а.качественное проектирование
б.контроль написанного кода коллегой или руководителем групппы.

Вот тут спор на соседней ветке про то что лучше C# или С++, так вот, мне этот спор (в современных условиях в переносе на современный технологический уровень) напоминает спор жителей двух африканских племен - что вот грошки глиняные делать чисто руками или деревянный скребок использовать?

Ко мне давеча подошел наш маркетолог и говорит нужно блокировать возможность продаж через чистему при условии что товар обладает свойтсвом А, клиент свойством Б, а сектор продаж относится к сектору С. Сел рядом и начал смотреть - ну интересно ему как там и что я делать буду.
Я начал "шерстить" сохраненные процедуры, справочники и таблицы. Он и спрашивает - а что не т такого места в системе в котором эти условия нужно прописать логическими формулами и все будет работать. Я говорю - нет, нужно произвести изменениия не менее чем в трех процедурах и еще одной программе которая печатает отчет.
Потому что понятие продажи включает в себя:
1) Предложение клиенту
2) Прием о обработка заявки
3) Отгрузка
4) Распечатка документов

Он офигел (маркетолог).

Как я уже писал в предыдущих постах одно и тоже "знание" о процесее применяется в различных частях систмы при её проектировании и воплощении в кодах, в различных её уровнях и на разлдичных этапах её рабочего цикла.

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

Пример многосвязанного понятия - ПРОДАЖИ. Очень комплексное и емкое понятие.

Однако есть системы (например документооборота) в которых такие емкие обхъекты "живут". Но как правило разновидности объектов заданы жестко и зашиты в кодах более низкого уровня. Объекты нельзя скрещивать и видоизменять выводя новые "сорта". Поэтому данные системы остаются безвестными и применимы только в очень специальных областях применения.

Mainframe_старый AlexsalogКо мне давеча подошел наш маркетолог и говорит нужно блокировать возможность продаж через чистему при условии что товар обладает свойтсвом А, клиент свойством Б, а сектор продаж относится к сектору С. Сел рядом и начал смотреть - ну интересно ему как там и что я делать буду.
Я начал "шерстить" сохраненные процедуры, справочники и таблицы. Он и спрашивает - а что не т такого места в системе в котором эти условия нужно прописать логическими формулами и все будет работать.

Приведенная Вами задача хорошо ложится на BPMS. Но в моем видении BPMS пока не хватает онтологичности. То, что вы дальше пишете , в чистом виде онтологический подход. Но реализация таких систем - это процесс , т.е. он идет. (сами по себе системы проектирования онтологий - они есть и их много и давно, а вот системы реализующие деятельность на базе таких описаний - это реже. Бесспорно, они тоже есть, но их не всеобъемлюще.

Я находил в инете только касательно баз знаний. Говоря обращзно на базе онтологий реализуются пассивные ХРАНИЛИЩА. Если можно - есть ли пример системы на баще онтологий с "активной жизненой позицией"? Которая что то делает и обрабатывает.

Воть

Особенно по теме:
про пользовательский интерфейс