|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Codenamed может быть, например, какие-то типовые очень конструкции есть, из которых можно сложить код хотя бы процентов на 50? Тогда всяко меньше работы надо будет делать руками. нет такого, и в скором времени не наблюдается. Все попытки универсального, настолько сырые и дорогие, что смахивают на голимую рекламу. AlexTheRaven MHO в каком-нибудь одном, но качественно. Всё равно на всех не угодите. +1 если заказчик дейсвительно важен, то пусть оплачивает создание в вашей организации доп.направления на перенос кода (уже отлаженного на одной платформе). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 10:11 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
AlexsalogЯ конечно же скажу глупость, но в идеале мне видится так: надстройка времени разработки, оперирующая понятиями бизнес-логики. Ну почему же глупость? Вовсе нет. Только какие они - понятия бизнес-логики? Вот в чем вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 11:26 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Codenamed AlexsalogЯ конечно же скажу глупость, но в идеале мне видится так: надстройка времени разработки, оперирующая понятиями бизнес-логики. Ну почему же глупость? Вовсе нет. Только какие они - понятия бизнес-логики? Вот в чем вопрос. простейший случай - хранимая процедура "Создать счёт" (правда автогенерацией кода здесь не пахнет). ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 11:53 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Читаю этот топик и удивляюсь :) - в технологии EJB предусмотрен доступ для клиентов через SOAP или CORBA, что позволяет писать клиента почти на любом ЯП. - в технологии EJB запросы к БД описываются на языке Java Persistence Query Language который транслируется ORM-менеджером в native SQL запросы конкретной БД - сами EJB-компоненты пишутся на Java и не зависят от используемого Application Server-а, т. е. могут считаться межплатформенными - зачем изобретать велосипеды когда все уже придумано? прошу не считать мое замечание выпадом против других существующих технологий, просто мне кажется что с помощью технологии EJB вполне возможно решить задачу поставленную автором топика. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 12:38 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Codenamed AlexsalogЯ конечно же скажу глупость, но в идеале мне видится так: надстройка времени разработки, оперирующая понятиями бизнес-логики. Ну почему же глупость? Вовсе нет. Только какие они - понятия бизнес-логики? Вот в чем вопрос. Тут полная свобода творчества. Мир, который проектируется с нуля. Например (держу перед мысленным взором нашу систему) - нам бы подошли: На верхнем, самом агреггированном уровне: Код: plaintext
Код: plaintext 1.
под '=(*)=>' подразумеваются отношения, цифра в скобочках - идентификатор. [Бизнес-правила] могут влиять на: - видимость Атрибутов, - на возможность присвоения значений Объектов данных документам и - на осуществимость Переходов. [Бизнес правила] формулирутся в терминах Атрибутов, как условные выражения. Кроме вычисления условия, бизнес правило имеет несколько модификаторов Действие: - Запрет всего действия - Исключение мешающего элемента в ОбъектеДанных - Перемещение мешающего объекта в другую плоскость переходов Например: полный запрет формирования накладной из счета если один из товаров это грабли= Код: plaintext
Указанное правило легко транслируется, например в T-SQL: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 12:41 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
аффтар Пусть есть некоторое решение по автоматизации, разработанное и внедренное для одного заказчика, скажем, на MS SQL + .Net. Потом приходит второй заказчик Kachalov - зачем изобретать велосипеды когда все уже придумано? прошу не считать мое замечание выпадом против других существующих технологий, просто мне кажется что с помощью технологии EJB вполне возможно решить задачу поставленную автором топика. всё выкинуть и переписать? ДОрого! Alexsalog Например: полный запрет формирования накладной из счета если один из товаров это грабли= слабоватое бизнес-правило. 2. Такое уже есть в ErWin - генератор кода на шаблонах под каждую СУБД. Только вот, неприжилось... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 13:01 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
2Kachalov: а можно ссылочку, где хорошо написано про Java PQL? Судя по описаниям, это действительно нечто близкое к решаемой задаче. Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 15:55 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
2Alexsalog: Любая свобода, а тем более творчества, в нашем деле - проблема, а не плюс. Идеальным вариантом является взять готовое решение, и либо купить его, либо сделать свою реализацию, которую можно будет подкручивать. Поэтому и интересно узнать, кто с таким сталкивался или пытался делать. Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 15:58 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
AlexTheRavenЗаинтересованное лицо, которое выдвигает требования относительно средств реализации, обладает нездоровым техническим бэкграундом. Какая ему разница, из чего скомпиллирован исполняемый файл - из .Net или Delphi? У него где-то остались рабочие станции на Windows 95? Или он серьёзно рассчитывает, что ему дадут исходники и он будет самостоятельно копаться в чужом коде? Поговорите с заинтересованным лицом позицией повыше. Оно, скорее всего, скажет, что средства реализации ему почти безразличны, и максимум, что ему важно - это ОС. Я работал в банке. Была куплена банковская АБС. Работала она на Oracle и до сих пор работает. Причем огромным плюсом ее было то что исходники ее были открыты. Мы постоянно в ней что-то доделывали или как минимум смотрели как и что работает. Можно сказать что это было неправильно и надо было делать заказы у разработчика. Только разработчик просто не в силах был удовлетворить все запросы клиентов. И для нас было принитцпиально то что она работала на Oracle, потому что все кадры тех поддержки были заточены под Oracle и под эту АБС. Людям позицией выше было все равно на чем она будет написана, они считают деньги: если есть готовая платформа за лицензию которой уплачено, если есть техника под эту базу/операционку, и самое главное люди, умеющие работать с такими программами/системами, то в реальности переход на другую платформу был бы сродни закрытию банка на неопределнный срок, это не считая прямых затрат. Так что не все так просто с выбором операционки и базы. Насчет Win95 - к примеру у нас есть организации (ФСБ, ЦБ ) ради которых приходится до сих пор использовать дискеты - и это в 21 веке. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2008, 16:22 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Codenamedа можно ссылочку, где хорошо написано про Java PQL? Java Persistence Query Language ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2008, 11:13 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
chpЯ работал в банке. Была куплена банковская АБС. Работала она на Oracle и до сих пор работает. Причем огромным плюсом ее было то что исходники ее были открыты. Мы постоянно в ней что-то доделывали или как минимум смотрели как и что работает. Можно сказать что это было неправильно и надо было делать заказы у разработчика. Только разработчик просто не в силах был удовлетворить все запросы клиентов. Наверняка до этой АБС была какая-то другая, пусть даже "лоскутная". Для неё была инфраструктура, и у кадров тех. поддержки также были по ней какие-то знания. И тоже некоторое время банк был в подвешенном состоянии. Но это никого не остановило, т.к. новая АБС давала большие преимущества и/или кто-то получил за неё хороший откат. chp И для нас было принитцпиально то что она работала на Oracle, потому что все кадры тех поддержки были заточены под Oracle и под эту АБС. Так был ли Oracle в банке до этой АБС? chp Людям позицией выше было все равно на чем она будет написана, они считают деньги: если есть готовая платформа за лицензию которой уплачено, если есть техника под эту базу/операционку, и самое главное люди, умеющие работать с такими программами/системами, то в реальности переход на другую платформу был бы сродни закрытию банка на неопределнный срок, это не считая прямых затрат. Так что не все так просто с выбором операционки и базы. Согласен, здесь, как и везде, нужно считать. Впрочем, переписывание и перетестирование АБС специально под ваш банк - по цене сродни созданию АБС с нуля. Наверное, для банков первой десятки, у которых тысячи сотрудников поддержки АБС и сотни серверов, это имеет смысл, для остальных - вряд ли. chp Насчет Win95 - к примеру у нас есть организации (ФСБ, ЦБ ) ради которых приходится до сих пор использовать дискеты - и это в 21 веке. Мы всё-таки обсуждаем коммерческие организации, основной целью которых является получение прибыли. Разработка ПО для гос. организаций, большинство из которых в силу различных причин очень неравномерно распределяют деньги на IT - отдельный вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2008, 12:46 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Petro123 2. Такое уже есть в ErWin - генератор кода на шаблонах под каждую СУБД. Только вот, неприжилось... Почему не прижилось? У нас впролне успешно тригеры генерит. Делал, правда, не я, поэтому начаьные затраты мне неизвестны. А так - работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2008, 18:03 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Николай1 Petro123 2. Такое уже есть в ErWin - генератор кода на шаблонах под каждую СУБД. Только вот, неприжилось... Почему не прижилось? У нас впролне успешно тригеры генерит. Делал, правда, не я, поэтому начаьные затраты мне неизвестны. А так - работает. - код на макросах ErWin совершенно нечитабельный (в 10 раз больше, и т.д. и т.п.) - в ErWin не заложена декларативная ссылочная целостность (через Cascade) - порог вхождения программиста в код ErWin занимает кучу времени - при накате скриптов в БД средсвами ErWin, он пропускает некоторые ошибки (приходится генерить скрипт, а потом извне его накат) - .... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.06.2008, 09:25 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
от себя добавлю, что еще хочется иметь в своем распоряжении такие приятные вещи, как, например, Code Completion (a/k/a IntelliSence), в целом удобную IDE, ну и так далее. Пока наиболее близкое к желаемому - это код, использующий конструируемые запросы по типу (n)Hibernate, Java PQL, MS EntityFramework + LINQ. Видимо, как-то так. Ну а реально в тяжелых случаях (то есть, когда нужно руками писать эффективные запросы) не поможет и это. Похоже, надо сделать вывод: поддержка "кросс-платформенной" бизнес-логики - пока утопия. Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
02.06.2008, 17:33 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Кстати, в догонку пришла идея, как все-таки можно несколько облегчить себе жизнь. Проблема, которая занимает меня, состоит в следующем: хочется иметь возможность прописывать бизнес-логику так, чтобы ее потом можно было отрендерить для любой СУБД, для которой написан провайдер. Это не касается некоторого количества критичного в плане эффективности кода, который обречен быть переписанным для каждой платформы, но значительная экономия времени и нервов разработчиков (а кому нравится переписывать что-то один в один?) была бы, это факт. Ну и, конечно, при каждом переписывании неизбежны ошибки, которые надо еще найти, да и сопровождать одновременно две версии тяжело поддерживать. В общем, понятно. И написать ее в таком виде, в принципе, можно. С использованием средств, перечисленных в предыдущем посте. Но это намного менее удобно для отладки, чем непосредственно SQL-код, особенно если его писать в хранимых процедурах. Отсюда компромиссное решение - система изначально разрабатывается на конкретной СУБД, и лишь в том случае, если система или ее фрагменты понадобились где-то еще, имеет смысл один раз упереться и перенести уже отлаженную бизнес-логику с голого диалекта SQL на уровень промежуточного звена, непрерывно проверяя идентичность результатов выполнения кода. То есть система должна продолжать функционировать и проходить все тесты во время постепенного перевода бизнес-логики. Заодно станут видны места, заведомо не допускающие такого обобщения. Если повезет - получится достаточно эффективная кросс-платформенная бизнес-логика. Если ей удастся покрыть хотя бы 70% всего объема - жизнь станет чуточку лучше. Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
02.06.2008, 17:52 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
CodenamedКстати, в догонку пришла идея На посошок Идея не пришла в голову разделить бизнес-логику 1) по степени трудоемкости 2) по степени быстродействия Фмысл ! 1) Я могу реализовать логику ввода счета на интерпретаторе Фортрана написанного на Васике и никто не заметит что данное решение тормозит. 2) Но за такую реализацию отчета суммирования допустим итогов дня я буду два раза трижды четвертован Т. е. 1) переписываем только что критично 2) не забывая про прозрачность рашения ______________________________________________________ Задолбали вихри яростных атак ... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.06.2008, 20:05 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Codenamed Проблема, которая занимает меня, состоит в следующем: хочется иметь возможность прописывать бизнес-логику так, чтобы ее потом можно было отрендерить для любой СУБД, для которой написан провайдер. ... И написать ее в таком виде, в принципе, можно. Можно, можно. Только, как правило, адаптация существующей системы под новую СУБД оказывается дороже, чем интеграция у заказчика в его инфрастурктуру другую СУБД. И даже если вы с самого начала начнете проектировать архитектуру под несколько СУБД - вы просто перенесете эти затраты на др. этап. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2008, 12:12 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
Да, всё так. Сложности действительно переносятся на другой этап. Поэтому смысл делать что-то подобное если и есть, то только тогда, когда ожидается массовое внедрялово одного и того же функционала разным заказчикам на разных платформах. В общем, ну его пока нафег :) Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2008, 16:24 |
|
Повторно используемая бизнес-логика
|
|||
---|---|---|---|
#18+
CodenamedПусть есть некоторое решение по автоматизации, разработанное и внедренное для одного заказчика, скажем, на MS SQL + .Net. Потом приходит второй заказчик и говорит: мы хотим то же самое (с некоторыми изменениями, конечно), но на Oracle + Java. А в очереди третий заказчик, который говорит: а мы хотим на MS SQL, но чтобы клиент на Delphi был. Все хотят дать много денег :) Соответственно, возникает вопрос: в каком виде следует реализовать бизнес-логику исходного решения, чтобы ее можно было без изменений перенести на другую платформу? Код: plaintext
Всё зависит от степени этих изменений - "с некоторыми изменениями, конечно". Быть может, это будут такие изменения, что лучше взять от старого проекта всё самое лучшее - прописанные бизнес-процессы, готовые библиотеки, архитектуру и, проведя предварительный анализ бизнес-процессов заказчика, разработать новый проект и внедрить. Не хватает данных для ответа на ваш вопрос. Для этого нужно знать, какой размер системы, насколько она покрывает потребности вашего предприятия, насколько она соответствует потребностям новых заказчиков и т.д. Если система достаточно большая, то и переделка может вылиться в стоимость разработки и внедрения новой системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.08.2008, 08:19 |
|
|
start [/forum/topic.php?fid=33&msg=35349697&tid=1548725]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
131ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 243ms |
0 / 0 |