webusНе знаю куда написать видимо сюда. Пишу приложения, и вдруг ловлю себя на мысли что я делаю это не так! Пишу обычные клиентские приложения под БД на C#.NET 2.0. Ощущение что я это делаю не так. Вроде все как обычно создается MDI-приложение. Главное меню, огромное количество дочерних окон.В базе пишется огромное количество хранимых процедур,для вставки,изменения,просмотра записей.В проекте для большей скорости не используются DataSet'ы. Настройки программы сохраняются, в файлах, имеющих "свой" формат (не XML).
Почти вручную заполняется DataGridView. Вручную же и ловятся выделенные в нем записи для изменения. Для обработки хранимых процедур пишется огоромное количество монотонного кода, разница в нем только кол-во параметров и название процедур.

Ощущение что я код пишу как то по старым привычкам, что есть уже новый подход, и приложения пишутся намного быстрее или я не прав ?

http://webusblog.blogspot.com/

В NET есть генерики, а вот на уровне SQL серверов нет. И я бы сказал - не хватает.

Или приходится генерить налету sql код в клиентском приложении.

Или тупо и монотонно писать дикое количество созраненных процедур и функций с тупо и монотоноо повторяющимся кодом.

Lepsik Alexsalog

Или приходится генерить налету sql код в клиентском приложении.



трындец sql серверу.

Почему? из за накладных расходов на компиляцию запроса на сервере?
В Оракле есть связанные переменные - да. Тут и Том Кайт советует и примеры дает - хотя в этой области я начинающий. В практической работе запрос все равно формируется как строка на клиентской стороне и отправляется посредством
В MS SQL - если sql запрос посылается с клиентской стороны, то я вообще не знаю у него никаких возможностей "предкомпиляции".

А ради:
писать SP - ну не знаю....
Можно коенчно и на это идти - ради "оптимизации", но именно это и превращает разработку в тот монотонный и повторяющийся процесс о котором говорилось в начале.

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 пока не хватает онтологичности. То, что вы дальше пишете , в чистом виде онтологический подход. Но реализация таких систем - это процесс , т.е. он идет. (сами по себе системы проектирования онтологий - они есть и их много и давно, а вот системы реализующие деятельность на базе таких описаний - это реже. Бесспорно, они тоже есть, но их не всеобъемлюще.

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

Воть

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

И опять же - если кто понимает о чем речь, то главнейшей проблемой в системах онтологии является не описание онтологий (это все банально и тривиально), а их маппирование друг на друга. По моему это уже на уровне подступов к ИИ.

Mainframe_старый AlexsalogИ опять же - если кто понимает о чем речь, то главнейшей проблемой в системах онтологии является не описание онтологий (это все банально и тривиально), а их маппирование друг на друга. По моему это уже на уровне подступов к ИИ.

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

То есть
авторВ разных местах одно и то же описание - НЕТ, не одно и тоже. Источник один, но от него берут начало другие онтологии с дополнительным (и дополняемым) собственным контекстом, но тем не менее жестко связанные с центральным описанием.

авторТ.е. как использовать описания для организации - бизнес-процессов, интеграции данных, автоматизации процедур поддержки качества данных, автоматизации управляющих воздействий, автоматизации процедур обеспечения безопасности. - это определяется активностью "исполнителя" - программы, которая собственно и производит активные действия.
Исполнитель может быть интерактивным (ждущий воздействия оператора) и активным - выполняющим действия по таймеру или в зависимости от изменения информационного окружения (т.е. вариант ожидания либо временного события, либо опрос состояния рядом живущих объектов).
Исполнитель - это как бы заряженный энергией демон, которого переполняют силы, но он не знает ЧТО ему делать и поэтому он работает (будучи запушенным) вхолостую. In idle.
Но как только он получает на вход (в виде последовательности байтов) описание задачи - ПОНЯТНОЙ ему (поэтому и онтология для исполнителя должна быть специализированной), он начинает пахать и сеять.

При этом работа может быть двух типов

1) Конечные действия (выполенние запросов, формирование интрефейса, расчет, сохранение и исзвлечение данных)

2) Трансферт - внесение изменений в активное состояние других онтологий с использованием структуры взаимосвязи.