ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Создание сервера приложений
440 сообщений из 440, показаны все 18 страниц
  все  
Создание сервера приложений
    #33279652
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Спешу нарваться на гнев посетителей форума, но найти по моей проблеме ничего не удалось.
Двухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений? (Используем VB.Net + MS SQL Server 2000 (или 2005))
Конкретнее: интересует конкретная реализация механизмов получения запросов от клиентов, их обработка и отсылка результатов, причем все эти процессы от разных клиентов должны вестись параллельльно (естественно).
...
Рейтинг: 0 / 0
20.09.2005, 17:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33279722
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolobok0
Участник
Простой рабочийСпешу нарваться на гнев посетителей форума, но найти по моей проблеме ничего не удалось.
Двухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений? (Используем VB.Net + MS SQL Server 2000 (или 2005))
Конкретнее: интересует конкретная реализация механизмов получения запросов от клиентов, их обработка и отсылка результатов, причем все эти процессы от разных клиентов должны вестись параллельльно (естественно).

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

Про ссылки - не встречал. По крохам в основном. Из разных операционок. сам пасся на новеловских изданиях (именно по сервакам приложений и апи юзанья) в основном.

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

Ну например...
Если откроем юниксовые самплы, то видим что связь идёт по клиентно. По клиентно предлагаеться обрабатывать сами поступающие запросы. уровень, как правило избираеться TCP.
А вот из опыта имею и немного другие схемы... например связь на уровне UDP. весь сервак сделан по задачно. приёмник общий на всех. слой общения с базой один на всех. есть лист текущих конекшеннов ну и т.д.. Такая схема обусловленна повышенной надёжностью и скорострельностью под конкретную задачу.
Возможны смешанные варианты...

вообщето тема очень интересная и обьёмная...
посему - тут лучше копать примеры...мне так икаеться. пробовать...
да, обычно на сервак накладывает сильный отпечаток OS (синхро обьекты и прочее) - посему универсальное делать, на мой взгляд, глупо.
Да, на этапе проектирования не забудьте аспекты секьюритей, многопользовательского доступа, отказоустойчивости, ударопрочности...

с уважением
(круглый)
...
Рейтинг: 0 / 0
20.09.2005, 18:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33279728
Lepsik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lepsik
Участник
Простой рабочийКонкретнее: интересует конкретная реализация механизмов получения запросов от клиентов, их обработка и отсылка результатов, причем все эти процессы от разных клиентов должны вестись параллельльно (естественно).

все зависит от специфики. В иных случаях сервисы могут обмениваться данными через базу, в иных через сокеты.
...
Рейтинг: 0 / 0
20.09.2005, 18:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33281161
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторДвухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений?

А вам зачем трехзвенное? Просто так или делать нечего? :))

-- Tygra's --
...
Рейтинг: 0 / 0
21.09.2005, 13:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33281386
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>Простому рабочему
Если Вас интересует суть дела и вопрос как именно можно построить многозвенку, то посмотри здесь:
http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx

и рассмотри переход с васика на C# (иногда важны многофайловые сборки)

С уважением, Владимир.
...
Рейтинг: 0 / 0
21.09.2005, 14:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33282508
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Так_забежал_просто
Участник
Если сервер приложений написать на хранимых процедурах БД, это понизит требования к разработчикам (всё-таки, хорошие двуязыкие программисты не так уж часто встречаются) и упростит систему. Минусы - появляется привязка к определённой СУБД, кроме того, внутренние языки БД (могу с уверенностью сказать только про PL/SQL) не обладают многими сильно желательными возможностями.
Кстати, кто-нибудь может сказать что-нибудь хорошее (или плохое) про всякие-разные готовые движки? Было бы интересно.
...
Рейтинг: 0 / 0
21.09.2005, 21:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33282738
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Спасибо всем за отзывы.
Извиняюсь за задержку, вчера весь день провёл на конференции.

tygra авторДвухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений?

А вам зачем трехзвенное? Просто так или делать нечего? :))

-- Tygra's --

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

Хорошее предложение поступило насчет хп сервера, но это, ИМХО, удобно реализуемо только на MS SQL Server 2005 (из линейки майкрософт).
...
Рейтинг: 0 / 0
22.09.2005, 08:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33282756
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
ВМоисеев
1. Ссылка не совсем в тему. В ней рассматривается вопрос защиты.
2. Чем С# лучше VB.Net в реализации сервера приложения?

kolobok0
Не забывайте, с кем общаетесь ;-) (см. ник) Много непонятного...

Наверное, лучше своё представление рассказать.
1. Запущена программа (П), которая держит N соединений от клиентов и N соединений к БД.
2. При получении запроса (П) запускает соответствующий процесс на выполнение (либо он уже запущен - тогда просто выполняется).
3. Результат выполнения передаётся к (П) и далее к клиенту.
...
Рейтинг: 0 / 0
22.09.2005, 08:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283259
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>Простому рабочему
>1. Ссылка не совсем в тему. В ней рассматривается вопрос защиты.
>2. Чем С# лучше VB.Net в реализации сервера приложения?

1.Вы пожалуйста, прочитайте стаью по-внимательнее. Там есть решение вашей задачи.
2.Клиентское приложение - многофайловая сборка, не нашел способа сделать подобное на васике
...
Рейтинг: 0 / 0
22.09.2005, 12:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283370
kolobok0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kolobok0
Участник
Простой рабочий......... Много непонятного...своё представление рассказать.....

Если что то не понятно - спрашивайте, отвечу если смогу.
Представление...Кхм... есть опыт, не единичный. Реализация СИЛЬНО зависит от задачи. Если у Вас нет опыта - то возможны большие затраты на данное предприятие.

серваки это очень обширная тема - мона долго рассказывать..главное - хорошенько подумать перед тем как...я бы сказал, что опыт программирования плоских вещей - тут пригождаеться, но мало. Кстати тут ближе всех (к данной кочке мировозрения), мне кажеться - явисты... Основной плюс, мне так каеться, в серваке приложения - это свобода. Свобода решения, решения задачи под желания клиента. Тут воопще нет ограничений... Ну например, мона говорить о бизнесс процессах решаемых за ноль времени :) Либо уменьшении кода (кстати именно это я наблюдаю в данных архитектурах).

с уважением
(круглый)
...
Рейтинг: 0 / 0
22.09.2005, 12:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283695
vialexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vialexis
Гость
ВМоисеев>Простому рабочему
>1. Ссылка не совсем в тему. В ней рассматривается вопрос защиты.
>2. Чем С# лучше VB.Net в реализации сервера приложения?

1.Вы пожалуйста, прочитайте стаью по-внимательнее. Там есть решение вашей задачи.
2.Клиентское приложение - многофайловая сборка, не нашел способа сделать подобное на васике

А зачем, в двух словах (или более :), понадобилось использовать многофайловые сборки?
...
Рейтинг: 0 / 0
22.09.2005, 14:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283797
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Простой рабочийУ компании открываются отделения в других городах и есть потребность контролировать информацию на местах. Тонкий клиент с отдельным сервером приложений - как раз выход из ситуации.
Что вы имеет ввиду под "контролировать информацию на местах"?
Если держать всю информацию в центральном офисе, а отделениям давать доступ - я понимаю. Или другой смысл "контроля"?
Тонкий клиент - выход. Но не обязательно такой уж тонкий - обычный КС клиент.
Сервер приложений - совсем не выход.
Простой рабочийВторой момент - переложить всю логику на сервер, тем самым увеличив скорость проведения документов или формирования отчетов.
А у вас что, не так??? Вся логика на клиенте? Тогда у вас не КС-система :)
Простой рабочийХорошее предложение поступило насчет хп сервера, но это, ИМХО, удобно реализуемо только на MS SQL Server 2005 (из линейки майкрософт).
Почему только 2005? На любом сервере - хоть 2000, хоть на Оракле. Причем именно обычный сервер БД а не "сервер приложений на ХП"

==========

Итак.
Если у вас не КС-система (т.е. большая часть логики зашита в клиента и он получает значительные объемы информации, то бишь практически ф-с), то однозначно переписывать на нормальную КС.
Если все же КС, то есть простой выход - сервер БД так и остается и обслуживает все отделения. Клиент и система для отделений немного дорабатывается. Доработка заключается в следующем: ставится интернет-сервер (IIS например с asp.net), на котором крутятся вебсервисы , которые служат лишь ретрансляторами потока данных. Клиент отделения обращается не напрямую к БД, а к вебсервису, который сам уже лезет в БД, берет данные и передает обратно клиенту отделения. И наоборот. Получаем универсальную систему, которая работает одновременно в локальной и глобальной сетях без особых изменений.

Самый простой и самый хороший способ.
Никаких трехзвенок вам не нужно, и лучше их и не трогать.

-- Tygra's --
...
Рейтинг: 0 / 0
22.09.2005, 14:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283894
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
tygraЧто вы имеет ввиду под "контролировать информацию на местах"?

Я предполагаю не один сервер, а отдельный сервер в каждом отделении. "Контролировать информацию" - ревизорам из центра нужна он-лайн информация о состоянии дел в отделениях.
Почему не нравится вариантс одним сервером - каналы связи оставляют желать лучшего, отделения находятся в глубинках.
tygraА у вас что, не так??? Вся логика на клиенте? Тогда у вас не КС-система :)

Давайте не будем спорить КС или не КС. Есть MS SQL Server - уже КС. Где работает логика - на клиенте или на сервере - это другой вопрос. Не всегда удобно писать логику через хп, гораздо проще на клиенте. А в MS SQL Sever 2005 уже встрена платформа .Net, что в сотни раз облегчает написание модулей.

tygraвебсервисы
Это идея! Обдумаем...
...
Рейтинг: 0 / 0
22.09.2005, 15:01
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33283928
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Tygra
Говорят, IIS - слабое место MS в плане безопасности...
...
Рейтинг: 0 / 0
22.09.2005, 15:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33284753
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>Простой рабочий
>А зачем, в двух словах (или более :), понадобилось использовать многофайловые сборки?

Клиентское приложение представляет информацию клиенту в форме графических панелей (формы, UserControl) c графическими элементами (DataGrig, TextBox и т.п.). Не все бывают нужны клиенту в данной сессии. У меня графическая панель - сборка, это рассмотрено в конце статьи. Я отказался от вебсервисов - .Net Remote Service поверх IIS более практичны.

Крипто преобразования (безопасность) не выполняют singlecall сервисы на IIS. Они переписывают информационный пакет запроса в абонентские ящики и ждут ответа.
...
Рейтинг: 0 / 0
22.09.2005, 20:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33285889
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторЯ предполагаю не один сервер, а отдельный сервер в каждом отделении. "Контролировать информацию" - ревизорам из центра нужна он-лайн информация о состоянии дел в отделениях.
При чем тут тогда вообще трехзвенка????!!!!
авторДавайте не будем спорить КС или не КС. Есть MS SQL Server - уже КС. Где работает логика - на клиенте или на сервере - это другой вопрос.
Да нет, это как раз самый главный вопрос.
Если у вас вся логика на клиенте - то это продвинутый файл-сервер. Типа 1С v7..
Десятка - тоже машина якобы, и колеса есть, и руль... А хрен там - банка консервная, очень похожая на машину. :))
авторНе всегда удобно писать логику через хп, гораздо проще на клиенте.
Неа, просто уметь надо на сервере ее писать, или по крайней мере там логику исполнять, хотя лучше все же ее там и хранить, и писать, и исполнять. Как-то у меня получается - ну нет ничего на клиенте, кроме вызовов ХП.
авторА в MS SQL Sever 2005 уже встрена платформа .Net, что в сотни раз облегчает написание модулей
Вы в сотни раз, или даже в тысячи (1000) заблуждаетесь на счет этого. .Net на SQL Server никак вам не поможет. Чуда не будет - придется все-равно вам логику на сервер перекладывать, и все-равно с помощью ХП. :)) Так что лучше раньше начать чего-то делать, чем долго ждать и потом испытать разочарование.
авторГоворят, IIS - слабое место MS в плане безопасности...
Вообще говорят, что windows must die ...... Однако ничего, никто не умер, все работают. Лично мне нравится.

По вебсервисам:
Они помогут только в том случае, если логика на сервере. Иначе огромные объемы данных тягать туда-сюда.... Нехорошо получится, непроизводительно, да и не красиво :)

-- Tygra's --
...
Рейтинг: 0 / 0
23.09.2005, 13:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33286301
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеев>Я отказался от вебсервисов - .Net Remote Service поверх IIS более практичны.

Насколько я понял из МСДН, ремотинг-живой труп. Мелкософт теперь позиционирует его лишь как средство коммуникации между АппДоменами (внутри одного процесса) или для поддержки нестандартных транспорных протоколов.

Имхо связываться с ним сейчас уже не стоит, он вместе с ДКОМом медленно удаляется в страну вечной охоты :)
...
Рейтинг: 0 / 0
23.09.2005, 15:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33286316
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Простой рабочий Tygra
Говорят, IIS - слабое место MS в плане безопасности...
Проблем нет, юзай апаш :)
...
Рейтинг: 0 / 0
23.09.2005, 15:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33286484
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
DrKonito ВМоисеев>Я отказался от вебсервисов - .Net Remote Service поверх IIS более практичны.

Насколько я понял из МСДН, ремотинг-живой труп. Мелкософт теперь позиционирует его лишь как средство коммуникации между АппДоменами (внутри одного процесса) или для поддержки нестандартных транспорных протоколов.

Имхо связываться с ним сейчас уже не стоит, он вместе с ДКОМом медленно удаляется в страну вечной охоты :)
А что Вы посоветуете?

tygraПо вебсервисам:
Они помогут только в том случае, если логика на сервере
Мною логика предолагается ни на клиенте, ни на сервере, а именно в вебсервисах. Но это не значит, что не будет ни одной хп, ни одной функции.
...
Рейтинг: 0 / 0
23.09.2005, 16:35
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33286572
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Валентин К
Участник
Почитал вопросы и утверждения афтара топика и каменты.
И стало не чуждо написать пару заметок.

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

3-е звено - это подход+технология - это инструмент. Типо лобзика. А что им делать, это уже совсем другое дело. Так вот насколько я понял афтар не понимает, что же делать.... и берет инструменты всякие, например, может лобзик поможет понять, что же нужно делать.... Не прийми дорогой афтар это как надругательство над твоими проблемами, а как дружеское подтруниваие и конструктивную критику.

Такой вот вводный креатиф получилсо.
...
Рейтинг: 0 / 0
23.09.2005, 17:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33286874
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Простой рабочийМною логика предолагается ни на клиенте, ни на сервере, а именно в вебсервисах. Но это не значит, что не будет ни одной хп, ни одной функции.
И еще раз вам дам совет - пока не поздно, начинайте переходить на сервер БД ПОЛНОСТЬЮ : с логикой, ХП и т.д. Зачем себе жизнь усложнять?!

Или ФоксПро 2.6 никак не отпустит? :))

Вы не умеете держать логику на сервере? Так поможем.
Не хотите? А почему?
Или лень? Тут ничем помочь не могем :))

ЗЫ Логика в вебсервисах - это вообще кошмар!

Подсказка: а если завтра нужно будет к БД дать доступ и извне, и изнутри, вы будете и в ехе-шнике, и в вебсервисах, и еще хрен знает где дублировать (и менять каждый раз!!!) всю логику??? Очень хорошо, поздравляю, но мне такого даже за деньги не нать. :)) Я уж лучше в одном месте поправлю - а в трех заработает :))

-- Tygra's --
...
Рейтинг: 0 / 0
23.09.2005, 19:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287058
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Валентин К
Спорить не с чем и обижаться не на что - ибо прав на все 100. Но всё равно негоже посмеиваться над ребёнком, что он с ошибкой написал слово, так как ещё в школу не ходит.
Однако с шашкой на боку удалось штурмовать 2-хуровневую КС-систему и вполне удачно для первого раза. Учтены ошибки, проведён анализ. И под всеобщее ахание от 3-хуровневых систем захотелось сделать подобное. Но не знал, что этот подход не отработан в мире, поэтому и создал эту тему.

Валентин К1) Что хочет руководство. Часто что-то абстрактное.
А что делать?
Валентин К2) Что хочешь ты, афтар топика сделать на самом деле. ТО, что написано тобой в этом топике будет работать очень косо, если запуститсо ообще после долгих родов и стимуляции.
Спасибо за поддержку :)) Советуешь забить сразу, чтобы не терять времени?
Валентин К3) Дальше раскручиваем вопрос. Какая информация нужна в центральном офисе (ЦО). Это зависит от функций ЦО. Если просто смотреть, так это одно дело. А если управлять ценообразованием или нормированием - это совсем другое. От этого зависит на самом деле - что же собственно делать, чтобы это осуществилось.
ПРОСТО смотреть. Управлять какими-то процессами будут пользователи в филиала. Я, наверное, некорректо обозвал "филиал". На самом деле это полнеценные предприятия, но за которыми надо поглядывать в любой момент. И желательно из любой точки земли.
...
Рейтинг: 0 / 0
24.09.2005, 12:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287061
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
tygraИ еще раз вам дам совет - пока не поздно, начинайте переходить на сервер БД ПОЛНОСТЬЮ: с логикой, ХП и т.д. Зачем себе жизнь усложнять?!

Есть три момента, почему я не хочу этого делать, и поэтому не хочу усложнять СЕБЕ жизнь:
1) Произойдёт полное привязывание к конкретному СУБД и, если назреет необходимость поменять СУБД - мы просто не сможем этого сделать
2) Резко увеличится потребность сервера в оперативной памяти и частоте процессора. Почему именно мою систему ставили на предприятия - достаточно было дохлых серверов или даже рабочей станции с WinXP в качестве сервера.
3) Программеру, кроме знания VB.Net/C# необходимо ХОРОШО знать T-SQL.
Это моё ЛИЧНОЕ мнение.

tygraЗЫ Логика в вебсервисах - это вообще кошмар!
А для чего они тогда нужны? Не проще ли напрямую работать с БД?

tygraПодсказка: а если завтра нужно будет к БД дать доступ и извне, и изнутри, вы будете и в ехе-шнике, и в вебсервисах, и еще хрен знает где дублировать (и менять каждый раз!!!) всю логику??? Очень хорошо, поздравляю, но мне такого даже за деньги не нать. :)) Я уж лучше в одном месте поправлю - а в трех заработает :))

Я тоже хочу в одном месте - в сервере приложений. Это и подразумевается в трёхзвенке.
...
Рейтинг: 0 / 0
24.09.2005, 12:15
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287102
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Простой рабочий
1) Произойдёт полное привязывание к конкретному СУБД и, если назреет необходимость поменять СУБД - мы просто не сможем этого сделать
Имхо независимость от БД реально нужна только в 2 случаях: 1) если вы разработчик тиражируемого приложения, тогда это может расширить рынок сбыта 2) Если СУБД с которой вы работаете не Oracle, MS SQL или DB/2 - тогда рано или поздно придется думать о замене СУБД.

Простой рабочий
2) Резко увеличится потребность сервера в оперативной памяти и частоте процессора. Почему именно мою систему ставили на предприятия - достаточно было дохлых серверов или даже рабочей станции с WinXP в качестве сервера.
Сервер приложений не будет быстрее и эффективнее промышленной СУБД, аминь. Сервера приложений теоретически более масштабируемы. Но до вопросов связанных с масштабированием надо еще дорасти. Потребности в масштабировании обычно сильно преувеличиваются поставщиками соответствующих платформ :).

Простой рабочий
3) Программеру, кроме знания VB.Net/C# необходимо ХОРОШО знать T-SQL.
TSQL хорошо знать придется по-любому. А вот если сервер приложений будет делать работу сервера БД (изоляция, блокировки, сортировка, джойны, фильтры итп) то разработчикам кроме собственно бизнес-логики придется задумываться о действительно сложных вещах.
А теперь подумайте об отладке и поддержке вашего сервера приложений. Насколько я понимаю вы работали с MS SQL. Аналог EnterpriseManager'а вы еще сможете написать, но представьте во что обойдется вам инструмент-аналог SQLProfiler'а ?

Простой рабочий
tygraПодсказка: а если завтра нужно будет к БД дать доступ и извне, и изнутри, вы будете и в ехе-шнике, и в вебсервисах, и еще хрен знает где дублировать (и менять каждый раз!!!) всю логику??? Очень хорошо, поздравляю, но мне такого даже за деньги не нать. :)) Я уж лучше в одном месте поправлю - а в трех заработает :))

Я тоже хочу в одном месте - в сервере приложений. Это и подразумевается в трёхзвенке.
Имхо ключевая проблема серверов приложений - в отсутствии устоявшегося стандартизированного интерфейса к ним.
СУБД- очень зрелая технология используемая уже более 40 лет.
Использовать любую СУБД из любого приложения не проблема наверное уже лет 20.
С серверами приложений ситуация диаметрально противоположна.
Полный разброд и метания. У каждого апп-сервера свой интерфейс не совместимый более ни с чем.
Возможно веб-сервисы что-то изменят в этой ситуации, но сейчас имхо ничего еще не устоялось и каждые полгода меняется.
Покрутите в голове случаи использования вашей системы:
Пакетные задания из под шедулера-?, печатные формы для пользователей-?, ОЛАП-?, интеграция с офисными приложениями-?, распределенные транзакции-?, интеграция с другими системами-?
Из-за нестандартности интерфейса самопального сервера придется самому писать тонны кода, вместо использования стандартных решений.
А через годик выйдет Индиго, еще через парочку какое-нибудь Индиго-2, еще через год супер сервер окажется малопонятной системой работающей на устаревшей технологии, доступ к которой можно получить только через не поддерживаемый ни одним поставщиком интерфейс.
...
Рейтинг: 0 / 0
24.09.2005, 13:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287103
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
tygraЗЫ Логика в вебсервисах - это вообще кошмар!

А не могли бы поделиться конкретными причинами такого мнения.
Вопрос меня сейчас реально интересует в практическом плане - у нас тут активно дискутируются варианты типа толстый клиент - веб-сервис(с Б\логикой)- БД vs браузер-IIS-БД(с Б\логикой) и тому подобное.
...
Рейтинг: 0 / 0
24.09.2005, 14:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287125
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
vialexisУважаемые коллеги! Если вы упоминаете МСДН (ибо сие есть библия программера), то пишите урлы, плиз! И вам респект будет и другим жизнь облегчите.


Therefore, we recommend that you use .NET Remoting wisely, for custom message processing or in-process, cross-application-domain communications. Prefer ASMX instead wherever possible, or ES/COM+ where you need rich distributed-object semantics.

На самом деле я видел гораздо более конкретные утверждения на эту тему, сейчас не смог их найти. Когда Микрософт выпускает что-то новое он начинает рассказывать интересные вещи о своих предыдущих технологиях :)
...
Рейтинг: 0 / 0
24.09.2005, 14:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287574
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Простому рабочему.

>ПРОСТО смотреть. Управлять какими-то процессами будут пользователи в филиала. Я, наверное, некорректо обозвал "филиал". На самом деле это полнеценные предприятия, но за которыми надо поглядывать в любой момент. И желательно из любой точки земли.

Если Вы на самом деле собираетесь создавать нечто подобное, советую еще раз повнимательнее проанализировать статью.

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

Не стоит вести управление из среды веб сервисов. Никаких крипто операций в их среде. Здесь никаких операций с конфиденциальными данными. Слишком высока возможность доступа к функциональности этого слоя постороннними.

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

И т.п.

С уважением Владимир.

p.s. Разница между .Net Remote Service поверх IIS и Web Service невелика. В первой редакции статьи тащил три варианта. Не смог обработать внешнее событие в среде веб сервиса. То что придет на смену Remoting неизбежно будет функционально близко к .Net Remoting. Так что мало потеряете.
...
Рейтинг: 0 / 0
25.09.2005, 22:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33287726
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
ВМоисеевПростому рабочему.

Надо учитывать высокую вероятность нежелательного перехвата конфиденциальной информации посторонними лицами. Вы обязаны криптографически защищать трафик.
. (?) (ссылка в предыдущем сообщении)
Enhance Your Services with WSE If You Need to Support WS-*
One of the limitations of today's "first-generation" Web services is that they don't provide a mechanism for end-to-end data security or integrity. It should be no surprise, therefore, that the first advanced Web services protocol defined was WS-Security.

If your application requires messages to be signed and/or encrypted, then you should enhance your ASMX service using Web Services Enhancements (WSE) for Microsoft .NET. WSE is a .NET technology that enables you to adopt WS-* protocols within your systems today. With a small amount of code and configuration, you can secure your Web service traffic against prying eyes or malicious network agents.

Importantly, WSE 3.0, which will ship shortly after the .NET Framework 2.0, will be wire-level compatible with "Indigo". This means that if you enhance your ASMX services with WSE 3.0, they will integrate with "Indigo" without requiring any code changes!
...
Рейтинг: 0 / 0
26.09.2005, 08:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33288238
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Простому рабочему и Пользователю,
>(?) (ссылка в предыдущем сообщении)
Enhance Your Services with WSE If You Need to Support WS-*

Так это здорово, если Билл сиё реализует. Будем применять. Но есть небольшое но... Крипто здорово подсаживает процессор (сейчас не говорят о 48 битном крипто - реально минимум 3DES). Поэтому задача распараллеливания вычислительных операций в сети по-прежнему актуальна.

С уважением, Владимир.
...
Рейтинг: 0 / 0
26.09.2005, 11:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33288351
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеев То что придет на смену Remoting неизбежно будет функционально близко к .Net Remoting. Так что мало потеряете. На смену ремотингу придет индиго-оно с ремотингом не совместимо.

ВМоисеевПростому рабочему и Пользователю,
>(?) (ссылка в предыдущем сообщении)
Enhance Your Services with WSE If You Need to Support WS-*

Так это здорово, если Билл сиё реализует. Будем применять. Но есть небольшое но... Крипто здорово подсаживает процессор (сейчас не говорят о 48 битном крипто - реально минимум 3DES). Поэтому задача распараллеливания вычислительных операций в сети по-прежнему актуальна.
Имхо автор имел в виду, что проблемы с безопасностью веб-сервисов на которые вы указали уже решены\будут решены в ближайшее время.

ВМоисеевПростому рабочему.
p.s. Разница между .Net Remote Service поверх IIS и Web Service невелика. В первой редакции статьи тащил три варианта. Не смог обработать внешнее событие в среде веб сервиса.
Никто не спорит что веб-сервисы функционально беднее. Зато это лишний раз заставляет разработчика задумываться о цене удаленного вызова иначе быстро можно прийти к сильносвязанной архитектуре.
...
Рейтинг: 0 / 0
26.09.2005, 12:22
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33288547
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Иногда бывает проще попробовать в реальной работе обсуждаемые архитектурные концепции. Очень легко и быстро это можно сделать, ознакомившись с демками и триальной версией продукта, взятого отсюда:
http://www.remobjects.com/page.asp?id={61C37C12-5E9F-4284-9659-F3E2AF8132F4}
...
Рейтинг: 0 / 0
26.09.2005, 13:13
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33289119
Хлюстов Кирилл
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хлюстов Кирилл
Гость
Я бы рекомендовал использовать для реализации сервера приложений библиотеку gSOAP . Компактно, прозрачно и не сложно. Это реализация работы по протоколу SOAP. Клиентские места можно разрабатывать в том числе и на VB.NET
...
Рейтинг: 0 / 0
26.09.2005, 16:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33289417
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
DrKonito tygraЗЫ Логика в вебсервисах - это вообще кошмар!

А не могли бы поделиться конкретными причинами такого мнения.
Вопрос меня сейчас реально интересует в практическом плане - у нас тут активно дискутируются варианты типа толстый клиент - веб-сервис(с Б\логикой)- БД vs браузер-IIS-БД(с Б\логикой) и тому подобное.

Я вообще за БЛ только на серевере БД, хоть с чем бы ни сравнивать - с сервером приложений, IIS, чертом лысым :))


-- Tygra's --
...
Рейтинг: 0 / 0
26.09.2005, 18:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33289447
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
tygra DrKonito tygraЗЫ Логика в вебсервисах - это вообще кошмар!

А не могли бы поделиться конкретными причинами такого мнения.
Вопрос меня сейчас реально интересует в практическом плане - у нас тут активно дискутируются варианты типа толстый клиент - веб-сервис(с Б\логикой)- БД vs браузер-IIS-БД(с Б\логикой) и тому подобное.

Я вообще за БЛ только на серевере БД, хоть с чем бы ни сравнивать - с сервером приложений, IIS, чертом лысым :))


-- Tygra's --
Я в принципе тоже.
Но моё эстетическое чуство слабый аргумент, когда начальство в очередной раз возвращается с микрософтовского семинара :)
...
Рейтинг: 0 / 0
26.09.2005, 18:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33289962
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
И что оно там узнает?
Надо мягко ему рассказывать, как БЛ на сервере объеденить с тем, чего они услышали, дополнить всеми плюсами БЛ на сервере - и все будет хорошо. :))

А что за семинары то? Где там микрософт предлагает БЛ где-то в другом месте?

-- Tygra's --
...
Рейтинг: 0 / 0
27.09.2005, 10:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33290477
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>DrKonito

>На смену ремотингу придет индиго-оно с ремотингом не совместимо.

Не имею такой информации.

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

Повторяю, крипто-операции сильно грузят процессор.
Думаю, что задача веб-сервиса поддерживать связь с клиентским приложением на время запроса/ответа (секунды, десяток секунд) и не более. Вычислительные операции должны выполняться слоями "бизнес-логики", на других цифромолках сети.

>Никто не спорит что веб-сервисы функционально беднее.

Дело скорее не в бедности, а в функциональной направленности. Использую для клиента winform интерфейс, по линиям качаю только данные. Мне не нужны все примочки сервиса для его работы с браузером. С другой стороны требовалось разработать архитектуру доступа с данным сервера тождественную, как для инета (SOAP), так и локальной сети (Binary).

>tyrga.
У нас с Вами разные концепции построения информационных систем. Для меня, это распределенные вычисления, где сервер данных делает только то, что необходимо - оперативно и качественно снабжает потребителя данными, и не более.
Хотелось бы обменяться мнениями по тому, как строить подобные системы. Вас это не интересует, уважаю Ваше мнение, уважайте и моё. И потом, это хорошо, если есть варианты решения данной задачи. К тому же, не все имеют Oracle.

С уважением, Владимир.
...
Рейтинг: 0 / 0
27.09.2005, 12:32
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33290645
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
tygraИ что оно там узнает?
Надо мягко ему рассказывать, как БЛ на сервере объеденить с тем, чего они услышали, дополнить всеми плюсами БЛ на сервере - и все будет хорошо. :))

А что за семинары то? Где там микрософт предлагает БЛ где-то в другом месте?

-- Tygra's --
Оно приходит набравшись слов типа апп-пулинг, ван-клик-деплоймент, компоненты, мнгозвенные приложения, НЕТ-Фреймворк, НЕТ-Фреймворк, НЕТ-Фреймворк ...
Т.к половины этих слов оно не понимает, а слов про бизнес-логику на транзакте там не говорилось, то ход его мыслей примерно таков- написать все на НЕТ и все будет зашибись - об остальном Микрософт позаботится.

Соответсвенно вооружившись такой стратегией начальство набрало несколько человек, которые на собеседовании говорили похожие слова. Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

Со своей стороны я пытаюсь продавить позицию, что логика должна быть хотя бы на сервере. В каком виде - это вопрос открытый. Наверное веб-сервисы не самое худшее, что может случиться, учитывая сложившуюся ситуацию :).
...
Рейтинг: 0 / 0
27.09.2005, 13:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33290711
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 DrKonito

Даааа, не позавидуешь.

ВМоисеевУ нас с Вами разные концепции построения информационных систем. Для меня, это распределенные вычисления, где сервер данных делает только то, что необходимо - оперативно и качественно снабжает потребителя данными, и не более.
А кто сказал, что сервер данных предназначен только для этого? Этак можно и в dbf данные держать - то же самое получится. Все-равно, что купить Камаз и возить на нем личный ноутбук, чтобы мощщщщно было.
Концепции концепциями, но делать что-то, что совсем не нужно и неудобно, в любом случае нехорошо.
авторХотелось бы обменяться мнениями по тому, как строить подобные системы. Вас это не интересует, уважаю Ваше мнение, уважайте и моё.
Уважаю - разве нет?
Я вообще Простому рабочему рассказывал :)
авторИ потом, это хорошо, если есть варианты решения данной задачи. К тому же, не все имеют Oracle.
Не все. Я тоже не имею Оракл. Кстати, причем тут он?

-- Tygra's --
...
Рейтинг: 0 / 0
27.09.2005, 13:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33295148
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito
>Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

Примерно что-то аналогичное сделал. Работает. Бизнес-логика на шарпе. Толстый клиент. По сетям гоняю только данные. Свой подход описал в цетируемой статье. Не подскажешь как связаться с твоими аппанентами?

С уважением, Владимир
p.s. Но никому никогда не втюхивал про пальмы. Люблю иметь про запас вырианты. Многозвенка - вариант решения задачи построения системы для обслуживания много-много клиентов. Если нет их, можно и другой вариант. Был бы он в копилке.
...
Рейтинг: 0 / 0
29.09.2005, 11:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33297572
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Извиняюсь за отсутствие, был в командировке в Москве, нашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.
Роберт Дж. Оберг "Технология СОМ+. Основы и программирование", 2000 (1)
Мартин Фаулер "Архитектура корпоративных программных приложений", 2004 (2)

Но прежде хочу поблагодарить Programmer_Ortodox
и Хлюстов Кирилл за ссылки.

Хоть (1) давненько издана - это хорошая азбука, так как всё сейчас базируется на СОМ. Позволю себе кое-что из неё процитировать.

"Может показаться, что двухуровневая система КС предоставляет почти полное решение, простое с точки зрения программной реализации благодаря использованию СУБД. Но что, если мы захотим решить дифференциальное уравнение в частных производных? Насколько мне известно, ни одна СУБД не способна на такой подвиг. Это означает, что код для решения уравнения должен находиться у клиента, и мы опять оказываемся в ситуации, когда требуется пересылка больших объемов данных от сервера к клиенту. Мы хотим, чтобы клиент был способен выполнить команду "решить уравнение". Необходимые при этом данные находятся на сервере, и хотелось бы, чтобы соответсвующий код выпонялся там же, с пересылкой клиенту только полученного результата"

От себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.
Так же в бухучете немало отчетов, которые нельзя посторить одним запросом, приходится часто обращаться к БД.

"Один из подходов состоит в увеличении возможностей базы данных, для того чтобы оснастить её языком программирования общего назначения, с помощью которого вы могли бы кодировать алгоритм решения дифференциальных уравнений в частных производных в пределах СУБД. Технически такой вопрос вполне реализуем, и некоторые фанатики баз данных горячо ратуют за него. Последний стандарт SQL содержит более 800 страниц - сравните это число со 100 первоначальными страницами, охватывающими все требования реляционных баз данных. Некоторая бизнес-логика может быть реализована в базе данных с помощью механизма хранимых процедур, но пытаться сделать из баз данных универсальный вычислитель вряд ли разумно. Кстати, это идёт вразрез с современным подходом модульности в программировании. Да и вряд ли покупатели захотят быть "заперты" в одной, пусть и очень сложной СУБД."

И ещё. Я не собираюсь спорить что лучше 2-х или 3-х уровневые системы. Хотелось бы услышать советы касаемой технологий от людей с опытом.
...
Рейтинг: 0 / 0
30.09.2005, 09:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33297652
Фотография !!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
!!!
Участник
Простой рабочий
"Может показаться, что двухуровневая система КС предоставляет почти полное решение, простое с точки зрения программной реализации благодаря использованию СУБД. Но что, если мы захотим решить дифференциальное уравнение в частных производных? "А вы действительно этого захотите? Я еще допускаю необходимость решения системы линейных уравнений, но вот дифуры в частных производных... В любом случае, для бизнес-приложения это очень частная задача.

Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.И что этот пример показывает, кроме низкого качества проектирования и реализации?
Простой рабочийТак же в бухучете немало отчетов, которые нельзя посторить одним запросом, приходится часто обращаться к БД.Для этого существуют хранимые процедуры
...
Рейтинг: 0 / 0
30.09.2005, 10:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33297658
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
OLAP - все что нужно для финансового и аналитического анализа. Как раз из разряда высшей математики:
http://www.sybase.com/content/1037447/olap.pdf

Далее - если чего то не хватает, в СУБД расширенные хранимые процедуры никто вроде не отменял. Пишем на Си, подключаем, пользуемся.

Далее - своя метаструктура в БД описывающая нужную модель бизнес-логики, процессы, разбитые по ХП, динамический SQL для сборки по метаструктуре и ХП нужных алгоритмов выполнения и имеет на борту мощный универсальный движок. Соотвествующе в качестве языка имеет мощный язык хранимых процедур, на котором легко писать, нет нужды озадачиваться доступом к данным в БД, легко компилировать, при желании хранить нужные скрипты в метаструктуре и через динамический SQL быстро производить сборку нужных скриптов или компиляцию типовых ХП.

авторнашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.
Было бы конечно странно, если бы они разубедили. Может быть теперь купить и почитать пару книжек, наоборот описывающих плюсы и ньюансы двухзвенных приложений и критикующих 3-х звенки ?

авторДа и вряд ли покупатели захотят быть "заперты" в одной, пусть и очень сложной СУБД
А вот это миф 3-х звенок. Ни один сервер приложений не сможет обеспечить одновременную ровную работу блокировочника и версионника на больших нагрузках. А если вспомнить все мощные отчетные системы, обожающие SQL, так вообще этот фактор оказывается большим костылем для 3-его звена, лично сам не раз наблюдал эту картину. В любом случае, будет ли 2-х звенка или 3-х звенка, придется для разных СУБД, пусть и имеющих одинаковую структуру, вести собственные запросы, оптимизированные под конкретную СУБД (для некоторых еще и под каждую версию) и скрипты бизнес-логики. А где и как удобнее хранить такие скрипты, не озадачиваясь правами доступа и желая легкость их вызова - правильно, в хранимых процедурах - название само за себя говорит. Так же не вижу ничего страшного в том, чтобы запереть покупателя в пределах одной СУБД, если у нее будет низкая стоимость покупки, владения и сопровождения и нормальные интеграционных механизмы для обеспечения интеграции с другими продуктами и СУБД у покупателя.

Таким образом лично для меня 3-е звено и попытки впихнуть ООП в релляционную логику остается загадкой природы. Я в своей жизни кстати не встречал 3-х звенщиков, которые бы могли похвастаться глубокими познаниями в РСУБД, вот Java, C и ООП они знали прекрасно - это да. Сам я лично тоже балуюсь по мере надобности COM-серверами и технологиями распределенного доступа в нужных мне направлениях, но как то ни разу мне применить эти знания для построения 3-х звенной архитектуры мысли такой не возникало, все решалось стандартными средствами, где в БД помимо самих данных на себе описывала и хранила модель и процессы бизнес-логики, а клиентские приложения только вызывали нужные ХП и занимались своими основными задачами - построением для пользователя удобного и адекватного интерфейса.
...
Рейтинг: 0 / 0
30.09.2005, 10:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33298969
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Мдааааа....
авторИзвиняюсь за отсутствие, был в командировке в Москве, нашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.
А вы когда рекламу смотрите, неужели там говорят: а вот новая модель утюга, какой это ужасный утюг, он хуже всех гладит ваши брюки, не покупайте его, не покупайте и не пользуйтесь
авторХоть (1) давненько издана - это хорошая азбука, так как всё сейчас базируется на СОМ.
О, это точно, СОМ - это круто! Как без него прожить?
Правда я признАюсь - не знаю я СОМ, не знаю даже точно, как переводится это слово, не говоря уж о том, как работает и зачем оно. И ничего - никто не умер, ни я, ни мои заказчики. Постараюсь продержаться до пенсии без таких слов :))
авторМожет показаться, что двухуровневая система КС предоставляет почти полное решение, простое с точки зрения программной реализации благодаря использованию СУБД. Но что, если мы захотим решить дифференциальное уравнение в частных производных? Насколько мне известно, ни одна СУБД не способна на такой подвиг. Это означает, что код для решения уравнения должен находиться у клиента, и мы опять оказываемся в ситуации, когда требуется пересылка больших объемов данных от сервера к клиенту. Мы хотим, чтобы клиент был способен выполнить команду "решить уравнение". Необходимые при этом данные находятся на сервере, и хотелось бы, чтобы соответсвующий код выпонялся там же, с пересылкой клиенту только полученного результата
Ужасный бред! Причем с помесью противоречивых выводов.
А если вам необходимо рассчитать ядерную реакцию по делению плутония в реальном времени - вам не поможет ни трехзвенка, ни все компутеры вместе взятык, находящиеся в радиусе трех километров вокруг.
авторОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.
Так же в бухучете немало отчетов, которые нельзя посторить одним запросом, приходится часто обращаться к БД.
Это говорит о том, что вы не умеете работать с sql, с ХП и т.д.
...
Про остальные маркетинговые вырезки из якобы умных книг промолчу.

авторИ ещё. Я не собираюсь спорить что лучше 2-х или 3-х уровневые системы. Хотелось бы услышать советы касаемой технологий от людей с опытом.
Извините, но как вы можете спорить, если ни того, ни того до нужной степени не знаете?

ЗЫ Присоединюсь к совету: купите пару хороших книжек по к-с программированию и будет вам щастте. Если конечно есть такие книжки.

-- Tygra's --
...
Рейтинг: 0 / 0
30.09.2005, 16:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33299025
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Простой рабочий"Может показаться, что двухуровневая система КС предоставляет почти полное решение, простое с точки зрения программной реализации благодаря использованию СУБД. Но что, если мы захотим решить дифференциальное уравнение в частных производных? Насколько мне известно, ни одна СУБД не способна на такой подвиг. Это означает, что код для решения уравнения должен находиться у клиента, и мы опять оказываемся в ситуации, когда требуется пересылка больших объемов данных от сервера к клиенту. Мы хотим, чтобы клиент был способен выполнить команду "решить уравнение". Необходимые при этом данные находятся на сервере, и хотелось бы, чтобы соответсвующий код выпонялся там же, с пересылкой клиенту только полученного результата"

СУБД наверное не сможет (хотя, если постараться...), а вот C++ и Extended stored procedures в MSSQL да. Писали мы кое что похожее...

Простой рабочий"Один из подходов состоит в увеличении возможностей базы данных, для того чтобы оснастить её языком программирования общего назначения, с помощью которого вы могли бы кодировать алгоритм решения дифференциальных уравнений в частных производных в пределах СУБД. Технически такой вопрос вполне реализуем, и некоторые фанатики баз данных горячо ратуют за него. Последний стандарт SQL содержит более 800 страниц - сравните это число со 100 первоначальными страницами, охватывающими все требования реляционных баз данных. Некоторая бизнес-логика может быть реализована в базе данных с помощью механизма хранимых процедур, но пытаться сделать из баз данных универсальный вычислитель вряд ли разумно. Кстати, это идёт вразрез с современным подходом модульности в программировании. Да и вряд ли покупатели захотят быть "заперты" в одной, пусть и очень сложной СУБД."

Аргумент типа "это идёт вразрез с современным подходом..." как то не впечатляет... Да и расхожий аргумент "покупатель не захочет быть завязан на одну БД" уже нафталином провонял. А как насчет завязанности на J2EE или на .NET? Или на SAP? Или на Intel?

Кстати - еще один вариант 3х-звенной архитектуры: Ставишь 10 SQL-серверов - на одном лежат данные, а на других крутятся хранимые процедуры:)
...
Рейтинг: 0 / 0
30.09.2005, 16:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33299606
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
>Дмитрий Сорокин
>Кстати - еще один вариант 3х-звенной архитектуры: Ставишь 10 SQL-серверов - на одном лежат данные, а на других крутятся хранимые процедуры:)

И я за тоже, но только не 10 SQL серверов, а п (может быть и 10) серверов приложений, и крутятся на них нормальные сервисы (у меня .Net Remoting). И число n определяется экстремальными возможностями сервера данных по нагрузке, но их число априори значительно меньше числа клиентов.
Сервер приложений - например, Windows XP, число сервисов на нем определяется его возможностями (по памяти, мощностью цифромолки). Число серверов определяется задачей. Сервис - Ваша программа на доступных в среде .Net языках программирования. Сравните цены.

С уважением, Владимир.
...
Рейтинг: 0 / 0
30.09.2005, 23:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33300743
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Я таки скажу: нельзя ли огласить задачу, которая требует n серверов приложений или n sql серверов? Не теоретическую, а именно ту, которая сейчас использует эти n. Мне просто интересно - что это может быть. Вот смотрю на загрузку нашего сервера и думаю, чего нужно, чтобы не хватило этого и надо было поставить 10 серверов??? Не могу придумать. :)

-- Tygra's --
...
Рейтинг: 0 / 0
03.10.2005, 11:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33301578
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Простой рабочий
И ещё. Я не собираюсь спорить что лучше 2-х или 3-х уровневые системы. Хотелось бы услышать советы касаемой технологий от людей с опытом.
ОК, если забыть про книжки.
Я 1.5 года работал внедренцем , в скажем так Конторе1, продающей маленькую ЕРП на трехзвенке (на КОМе\ДКОМе), последние 2 года в Конторе2 занимаюсь разработкой и поддержкой нескольких обычных самописных клиент-серверов по функционалу близких к тому что я делал в Конторе1.

Сравнивая Контору1 и Контору2 отмечаю следующие факты:
1) 3х звенка тормозила на 30 пользователях, в Конторе2 нормально работают 200 пользователей, несмотря на то что половина мест на жутко неэффективном ацессе.

2) Класс разработчиков в Конторе1 был серьезно выше. Им приходилось заниматься действительно нетривиальными проблемами. Но не сказал бы что это является преимуществом 3х звенки :)

3) Любого человека который приходил в Контору1 надо было учить фактически с нуля. Первые полгода-год от новых людей было очень мало толку. В Контору2 можно взять студента на 400 баксов с базовым знанием SQL и быстро поставить его в строй.

4) В Конторе1 совершенно серьезно рассматривался вопрос, а не написать ли самопального ОлеДб провайдера, чтобы можно было пользоваться КристалРепортом. В виду невозможности использования стандартных средств отчеты делались на самопальном репорт-генераторе на базе икселя. Это к вопросу об интеграции с другими системами :)

Могу продолжить воспоминания, но собственно единственным вспоминающимся плюсом Конторы1 были мощные люди с которыми довелось поработать. Имен и названий не ждите, не хочу гадничать.
...
Рейтинг: 0 / 0
03.10.2005, 15:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33301604
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеевDrKonito
>Теперь эти люди ... , предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

Примерно что-то аналогичное сделал. Работает. Бизнес-логика на шарпе. Толстый клиент. По сетям гоняю только данные. Свой подход описал в цетируемой статье. Не подскажешь как связаться с твоими аппанентами?

не знаю каков в какой области работаете вы,
но имхо для внутрифирменного софта толстый клиент это настоящий кошмар в области техподдержки.

Кстати в несколько другой области лучшим примером толстого клиента является пресловутая 1С-ка. Она тоже по сети гоняет только данные :)
...
Рейтинг: 0 / 0
03.10.2005, 15:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33301829
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
tygraЯ таки скажу: нельзя ли огласить задачу, которая требует n серверов приложений или n sql серверов? Не теоретическую, а именно ту, которая сейчас использует эти n. Мне просто интересно - что это может быть. Вот смотрю на загрузку нашего сервера и думаю, чего нужно, чтобы не хватило этого и надо было поставить 10 серверов??? Не могу придумать. :)

-- Tygra's --
2 процессора - 4 гига оперативки - вся база под 10 гиг - и тормозит - если больше 10 клиентов -

и что теперь - новый сервер покупать?
...
Рейтинг: 0 / 0
03.10.2005, 16:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33301900
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
tygra

>Я таки скажу: нельзя ли огласить задачу, которая требует n серверов ...


Относительно задач можно посмотреть здесь
... топик - Трехзвенная архитектура
http://www.sql.ru/forum/actualthread.aspx?tid=214017

Подскажите пожалуйста характерристики Вашего железа и его стоимость.

С уважением, Владимир.
...
Рейтинг: 0 / 0
03.10.2005, 17:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33301902
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Пользователь tygraЯ таки скажу: нельзя ли огласить задачу, которая требует n серверов приложений или n sql серверов? Не теоретическую, а именно ту, которая сейчас использует эти n. Мне просто интересно - что это может быть. Вот смотрю на загрузку нашего сервера и думаю, чего нужно, чтобы не хватило этого и надо было поставить 10 серверов??? Не могу придумать. :)

-- Tygra's --
2 процессора - 4 гига оперативки - вся база под 10 гиг - и тормозит - если больше 10 клиентов -

и что теперь - новый сервер покупать?
Теперь нужно нанять специалиста, знающего досконально Вашу СУБД, обязательно с прямыми ручками, и заняться оптимизацией БД и запросов.
...
Рейтинг: 0 / 0
03.10.2005, 17:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302006
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторТеперь нужно нанять специалиста, знающего досконально Вашу СУБД, обязательно с прямыми ручками
Вот именно. Иногда даже помогает банальный просмотр логов выполнения SQL-операторов. Иногда просто взягляд со стороны.
...
Рейтинг: 0 / 0
03.10.2005, 17:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302305
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
Calm авторТеперь нужно нанять специалиста, знающего досконально Вашу СУБД, обязательно с прямыми ручками
Вот именно. Иногда даже помогает банальный просмотр логов выполнения SQL-операторов. Иногда просто взягляд со стороны.
Это подход самоделкинов, для тиражных продуктов - никто не будет ковырятся - проще и надежней - если имеется масштабируемость на уровне железа -

Другое дело - что масштабировать SQL сервера - и в теории почти невозможно.
...
Рейтинг: 0 / 0
03.10.2005, 19:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302459
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Из серии:
Я купил новую машину, мне сказали, что она мощная. Однако я умею переключать только на первую скорость и машина едет медленно. Вывод - куплю-ка я машину помощнее, тогда на первой скорости она обгонит мою нынешнюю машину
...
Рейтинг: 0 / 0
03.10.2005, 22:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302738
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
ASCRUSИз серии:
Я купил новую машину, мне сказали, что она мощная. Однако я умею переключать только на первую скорость и машина едет медленно. Вывод - куплю-ка я машину помощнее, тогда на первой скорости она обгонит мою нынешнюю машину
в такой терминологии - на машинах ездят люди - 99% которых не знает и не хочет знать устройство автомобиля

и если хочет ездить быстрее - естественно покупает другой автомобиль.
...
Рейтинг: 0 / 0
04.10.2005, 08:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302751
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
автори если хочет ездить быстрее - естественно покупает другой автомобиль.
Сами-то верите в то что пишите?

Продолжая аналогию:
Мой приятель недавно научился регулировать инжектор. Теперь он расходует меньше топлива. Видимо, это спасло его от приобретения нового автомобиля с более экономичными характеристиками?

Думаю, скоро он научится настраивать еще лучше и сэкономит стоимость еще одного автомобиля.
...
Рейтинг: 0 / 0
04.10.2005, 09:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302892
Так_забежал_просто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Так_забежал_просто
Участник
Пользователь
Это подход самоделкинов,

Не, ну как же так? А если всё тормозит какой-нибудь несчастный один отчёт, из-за того что там плохой запрос? Или просто надо настроить SQL-сервер?
Пользовательдля тиражных продуктов - никто не будет ковырятся - проще и надежней - если имеется масштабируемость на уровне железа -

Это не очень хорошо говорит об этих самых тиражных продуктах :) Что лучше, поковыряться немного в своём тиражном продукте, или чтобы тысячи клиентов разорились на новый сервер?
Пользователь
Другое дело - что масштабировать SQL сервера - и в теории почти невозможно.
Ну, есть репликации там всякие... И потом, ну, 4 гига оперативки. Ну, 2 процессора. Это не исчерпывающая характеристика сервера. А данные на чём сидят? Кстати, не может ли быть такого, что Вы упёрлись в потолок возможностей MS SQL (здесь я не особо представляю, о чём говорю, но, может, надобно оракл или дб2)?
...
Рейтинг: 0 / 0
04.10.2005, 10:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33302897
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторЭто не очень хорошо говорит об этих самых тиражных продуктах :)

Молодец, тактично сказал!
Я вот мужественно сдериваюсь, чтобы не высказаться о таких продуктах.
...
Рейтинг: 0 / 0
04.10.2005, 10:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303219
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Пользователь 2 процессора - 4 гига оперативки - вся база под 10 гиг - и тормозит - если больше 10 клиентов -
и что теперь - новый сервер покупать?

Обратный пример - самописная учетная система - типичная 2-х звенка, вся логика в хранимых процедурах, MSSQL, 600 одновременных пользователей, 300Gb база, 300млн. проводок, перелезли с 8хXEON700+8Gb RAM на 8xITANIUM2+8Gb RAM , потому что стало подтормаживать - теперь снова летает. Но, конечно, система вылизывалась достаточно долго.
Сервер масштабируется до 24 процессоров и 32Gb RAM, поэтому лет на 10-20 хватит.

При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.
...
Рейтинг: 0 / 0
04.10.2005, 11:44
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303573
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Мне кажется руки у вас росли нормально. DCOM - медленная штука.
...
Рейтинг: 0 / 0
04.10.2005, 13:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303748
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Дмитрию Сорокину

На ТЗ взглянуть нельзя ?

С уважением, Владимир.
...
Рейтинг: 0 / 0
04.10.2005, 14:01
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303759
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
CalmМне кажется руки у вас росли нормально. DCOM - медленная штука.
Э... а причем здесь ДКОМ?
ДКОМ это всего лишь инфраструктура для удаленных вызовов. В данном решении оно всего лишь что-то вроде транспорта между клиентами и серверами приложений.

К вопросам масштабирования имеет отношение связка сервера приложений-МТС-MS SQL.
...
Рейтинг: 0 / 0
04.10.2005, 14:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303831
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Дмитрий Сорокин[quot Пользователь ]
При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.

А вы действительно видели факт масштабирования?
Или просто нужно было еще 10 аппсерверов чтобы получить производительность близкую к двухзвенке? Соответственно, потянула бы такая система 600 клиентов при соответственно 20-30 апп серверах?
...
Рейтинг: 0 / 0
04.10.2005, 14:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33303896
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторДКОМ это всего лишь инфраструктура для удаленных вызовов. В данном решении оно всего лишь что-то вроде транспорта между клиентами и серверами приложений.
Разве я сказал что-то, что противоречило бы этому?
Подзреваю, что при 300 одновременных пользователей ДКОМ будет недостаточно быстрым транспортом.
...
Рейтинг: 0 / 0
04.10.2005, 14:39
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33304210
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Calm авторДКОМ это всего лишь инфраструктура для удаленных вызовов. В данном решении оно всего лишь что-то вроде транспорта между клиентами и серверами приложений.
Разве я сказал что-то, что противоречило бы этому?
Подзреваю, что при 300 одновременных пользователей ДКОМ будет недостаточно быстрым транспортом.
ОК, признаю тормоз мог быть и на стыке клиент-аппСервер.
Но 30 клиентов на АппСервер все таки не выглядит той цифрой на которой это могло произойти.
Скорее всего тормоз все таки на стыке АппСервера-МТС-БД.
...
Рейтинг: 0 / 0
04.10.2005, 16:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33304562
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну вот, тут ужо без меня ответили.

В общем, если руки прямые - проблем нет никаких.
Если обратное - хоть трехзвенка, хоть хрен знает что, толку не будет

Пользователь2 процессора - 4 гига оперативки - вся база под 10 гиг - и тормозит - если больше 10 клиентов -

и что теперь - новый сервер покупать?
Нет, лучше 10 (десять) нод под трехзвенку

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

-- Tygra's --
...
Рейтинг: 0 / 0
04.10.2005, 17:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33304905
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
ВМоисеевДмитрию Сорокину

На ТЗ взглянуть нельзя ?

С уважением, Владимир.

ТЗ? Их тысячи! Эта информационная система начинала создаваться в 1995г! на MSSQL 4.2.

Насчет MTS - вот, что тестировалось: Был написан СОМ-класс на С++ (насколько я помню - использовалась ATL, где есть готовый template для таких штук, но я могу ошибаться), в котором было 2 метода - подтверждение и отмена проводок. Логика была практически один к одному перенесена из аналогичных хранимых процедур. Конечно, совсем один к одному не получилось из-за отсутстыия в С++ таких вещей, например, как временные таблицы:), но вся логика и весь flow были сохранены. Класс регистрировался на MTC - серверах (характеристики машин сейчас не помню, вроде 2-х процессорные XEON 700 c 2 GB памяти) и проводились масштабные испытания - на тестовой базе тестовая программа открывет поток за потоком, каждый поток создавал инстанцию класса и проводил тестовые проводки.
На самом деле у нас стандартизирован набор разнообразных тестов - разные типы проводок, проводки сегодняшней датой, проводки задним числом и т.д. Потом меряется среднее кол-во проводок в секунду для возрастающего количества соединений. Вообщем, деталей уже не помню, но как мы ни вылизывали сишный код - результат был на порядок хуже прямой работы с MSSQL.

Потом мы пробовали просто создавать DCOM-обертки над хранимыми процедурами. Т.е. создается некий функциональный класс, в котором в виде методов описывались хранимые процедуры, а в коде методов эти процедуры вызывались. Результат был конечно лучше, чем вначале, но все равно хуже, чем при прямом использовании хранимых процедур - особенно на таких "быстрых" процедурах, как проведение проводок - там быстродействие доходит до сотен проводок в сек.
Но все бы ничего, и было бы интересно навесить "классовую" обертку на хранимые процедуры, но эта невозможность в MTS использовать т.н. stateful объекты! Т.е. значения свойств между вызовами объекта не сохраняются (чтобы их сохранить, надо было извернуться через одно место - либо использовать сессии, либо - таблицы БД либо сам придумай что), в результате чего подобные классы выраждаются в простые библиотеки функций, ничем не лучше хранимых процедур, т.е. ни о каком нормальном ООП в случае таких классов-оберток речи нет.
Может, конечно, в DCOM что и изменилось с тех пор - не знаю.

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

Речь не идет о переносе бизнес-логики куда-то на средний слой. Речь идет лишь о том, что вместо набора таблиц, вьюх и процедур программист (а в дальнейшем и продвинутый пользователь) работает с классами, свойствами и методами, т.е. использует объектную библиотеку, являющуюся интерфейсом к БД. В принципе ничто не запрещает использовать эти интерфейсные объекты, например, при написании скриптов на каком нибудь vbscript или С# с последующим запуском локально или на некоем дот-нетовском scripting host. Типа - вот вам и сервер приложений...
...
Рейтинг: 0 / 0
04.10.2005, 21:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33305418
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Дмитрию Сорокину.

Спасибо за информацию.
Вы правы относительно проводок. Операции диск-память значительно быстрее диск-память-сеть-память.
Я больше занимаюсь задачами построением выборок от многих клиентов и их предварительными обработками (некоторая математика, сжатие и шифрование). В этих задачах нет каскадного обращения к другим таблицам базы. Здесь сиьнее загружен процессор, а не тракты ввода/вывода.
Хотя многоуровневая модель не отказывается от хранимых процедур.

С уважением, Владимир.
...
Рейтинг: 0 / 0
05.10.2005, 10:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33305669
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Дмитрию Сорокину

Молодцы! Вот это я понимаю, люди грамотные работают. Я еще ни разу не слышал, чтобы кто-то подобное разрабатывал, да что разрабатывал, хотя бы придумал такое. Я такую систему спроектировал для .NET (доберусь ли до реализации не знаю), только я не собираюсь создавать по классу .NET для каждого класса в базе. Один единственный класс .NET, который предоставляет доступ к коллекции атрибутов и к коллекции методов. Набор атрибутов и методов класс получает из метаданных сервера.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
05.10.2005, 11:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33305693
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
На данный момент у меня есть реализация этого механизма на Дельфи. Из интерфейса самой программы создаете метаданные, т.е. регистрируете класс, добавляете атрибуты, создаете методы с кодом на T-SQL, затем компилируете и получаете таблицы и процедуры и данный класс уже готов к использованию в системе. Интерфейс даже проектировать не нужно. Сам подхватывает все описания и предоставляет формы.
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
05.10.2005, 11:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33306114
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Дмитрию Сорокину.
>В принципе ничто не запрещает использовать эти интерфейсные объекты, ...

Именно это и сделал на C#.
Плюс прозрачная схема доступа клиента к .Net Remote сервисам промежуточных слоев локальной сети из инета через IIS.

С уважением, Владимир.
...
Рейтинг: 0 / 0
05.10.2005, 13:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33307136
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Old NickНа данный момент у меня есть реализация этого механизма на Дельфи. Из интерфейса самой программы создаете метаданные, т.е. регистрируете класс, добавляете атрибуты, создаете методы с кодом на T-SQL, затем компилируете и получаете таблицы и процедуры и данный класс уже готов к использованию в системе. Интерфейс даже проектировать не нужно. Сам подхватывает все описания и предоставляет формы.
--------------------
Не учи отца и баста!

У нас несколько по другому. Уже существующие таблицы, вьюхи, хранимые процедуры и т.п. описываются в метаданных - поля - это свойства объекта, ссылки - это тоже свойства, но типа "объект", методы объекта - хранимые процедуры или откомпилированный .NET код (давай, вычисляй свои частные производные!). Можно создавать вычисляемые поля, составные свойства (типа структур - например валютная сумма и обозначение валюты), JOIN можно делать по нескольким полям, есть альтернативные ключи, и т.д. Плюс наследование и полиморфизм, плюс сам объект выступает не только как "одна запись" в БД, но и несет в себе методы навигации и интерфейсы, позволяющие ему работать как источник данных. Плюс свой транзакционный механизм - все изменения накапливаются, а потом одним махом сохраняются в БД. Плюс свои локи. Плюс своя security.
Для создания интерфейсов есть понятие визуализаций, которые тоже являются обладают всеми характеристиками объектов, и которые тоже описываются в метаданных (но можно и самим поизвращаться, сделав уникальную визуализацию). Пока разработана WIN32 визуализация, начали работать над WEB.

Кое что еще не доделано - надо доделать workflow, когда вводится понятие состояний объекта, в разных состояниях видны лишь определенные свойства и методы, и при этом различные методы в зависимости от их результата переводят объект в другие состояния (вообщем - почти конечный автомат). Не доделан механизм "раннего" оповещения об изменениях в БД (читай-серверные события) и механизм "кеширования" данных, когда лишь часть данных с сервера грузится на клиента, что очень важно для, например, WEB-интерфейса.

Вообще мы пытались построить полностью объектно-ориентированный интерфейс к БД со всеми аттрибутами ООП. ИМХО, такой подход позволяет достаточно быстро и, главное, с умом, создавать новые приложения и "рефакторить" старые наработки, когда существующая бизнес-логика и структуры просто описываются в метаданных.

Но все это не имеет ничего общего с общепринятой сейчас трехзвенной архитектурой и принудительного выноса бизнес-логики на средний слой. Да, при подобном подходе создается некая объектная оболочка над базой данных, но тут нет ничего общего с N-tier архитектурой SAPа или J2EEшных приложений.
Однако мне такой подход кажется более "приближеным к жизни", что-ли. Для меня главным преимуществом многозвенки является возможность "красиво организовать" свое приложение, работать не с таблицами и процедурами, а с объектами. Все таки (ИМХО) ООП по сравнению с классическим "функциональным" программированием имеет кучу преимуществ. Пусть за объектом стоят таблицы и хранимые процедуры - не важно. Важно, что наружу все это выглядит гораздо красивее. Плюс, что не маловажно - инкапсуляция (лучше иметь дело с объектом, чем с кучей хранимых процедур), наследование (есть объект - "клиент", создадим на его основе объект "поставщик"), повторное использование (уже есть объект "клиент", используйте его как справочник в своих приложениях, если надо - наследуйте от его базовой визуализации свою собственную). Плюс быстрота разработки...

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

Хотя все это ИМХО, и, возможно, мы изобретаем велосипед:)
...
Рейтинг: 0 / 0
05.10.2005, 17:37
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33307500
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Дмитрию Сорокину.

Кто и где выполняет откомпилированный .Net код и что это такое?

Дмитрий, давайте проведем мысленный эксперимент - у нас есть двухзвенная архитектура - ваш навороченный сервер, очень шустрая локальная сеть и такие же шустрые 600 клиентских компьютеров.

Включим комп 1 клиента и в цикле смоделируем вызовы тяжелых проводок. Получим мах. производительность для этого случая. Далее подключим еще один копм, затем еще и т.д. Где-то будет (N компов) некоторый оптимум производительности.

Зафиксируем это число и предположим что мы имеем эти N app серверов которые оптимально загружают сервер данных. Эти app сервера получают информацию по проводкам из некоторого буфера и сбрасывают результаты туда-же.

Где в этой модели понижение производительности?.
Каждый занимается своим делом параллельно.
Зачем серверу данных заниматься шифрованием выборки?

С уважением, Владимир.
...
Рейтинг: 0 / 0
05.10.2005, 20:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33307771
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Дмитрий СорокинТеперь мы делаем что-то похожее на .NET - логика остается на хранимых процедурах, но создаются классы-обертки, генерирущиеся автоматом на основе метаданных о структуре и взаимосвязях таблиц, вьюх, хранимых процедур и т.п.
Хотелось бы по-подробнее - что из себя представляют классы-обертки.
...
Рейтинг: 0 / 0
06.10.2005, 08:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33307935
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Простой рабочий Дмитрий СорокинТеперь мы делаем что-то похожее на .NET - логика остается на хранимых процедурах, но создаются классы-обертки, генерирущиеся автоматом на основе метаданных о структуре и взаимосвязях таблиц, вьюх, хранимых процедур и т.п.
Хотелось бы по-подробнее - что из себя представляют классы-обертки.

Поподробнее - это надолго:) В приаттаченом файле (это глава "введение" из хелпа для программистов) - находится краткое описание функционала библиотеки BaseObjects, которая как раз и создает объектное представление БД. Кроме этой библиотеки есть еще библиотека VisObjects для создания визуализаций.
...
Рейтинг: 0 / 0
06.10.2005, 09:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33307941
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Черт, что-то файл не приаттачился. Попытка номер 2:)
...
Рейтинг: 0 / 0
06.10.2005, 09:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33308124
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
DrKonitoTSQL хорошо знать придется по-любому. А вот если сервер приложений будет делать работу сервера БД (изоляция, блокировки, сортировка, джойны, фильтры итп) то разработчикам кроме собственно бизнес-логики придется задумываться о действительно сложных вещах.

Почему сервер приложений должен заниматься такими вещами, как изоляция, блокировки, сортировка, джойны, фильтры итп ?

DrKonitoИз-за нестандартности интерфейса самопального сервера придется самому писать тонны кода, вместо использования стандартных решений.

Это самый главный аргумент против СП. Но почему все ведущие производители ERP-систем используют n-звенную архитектуру и никто не держит бизнес-логику в хп? У меня есть пример одного предприятия, в котором из-за обилия и сложности хп на пределе работал 4-хпроцессорный сервер. Только не говорите, что у них кривая структура БД.

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

А не проще ли шифровать трафик на шлюзах в интернет?

tygraА кто сказал, что сервер данных предназначен только для этого? Этак можно и в dbf данные держать - то же самое получится.
Если Вы не понимаете, в чём разница между обработкой 10^n строк в СУБД и dbf - дальнейшее обсуждение не имеет смысла.

ВМоисеевDrKonito
>Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

Примерно что-то аналогичное сделал. Работает. Бизнес-логика на шарпе. Толстый клиент. По сетям гоняю только данные. Свой подход описал в цетируемой статье. Не подскажешь как связаться с твоими аппанентами?

Работать-то работает, пока эта задача не выйдет за пределы локальной сети.

!!! Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.И что этот пример показывает, кроме низкого качества проектирования и реализации?

tygra Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.Это говорит о том, что вы не умеете работать с sql, с ХП и т.д.

Я привёл пример размера кода не самого большого документа, а всего лишь алгоритма формирования бухгалтерских проводок накладной. Меня поразили Ваши ответы. У нас с Вами слишком больша разница в понятии бизнес-логики. Возможно я ошибаюсь, но вы не рабтали с ERP-системами (или хотя бы приближенными к ним).

ASCRUS Простой рабочийнашёл в книжном магазине пару интересных книжек по пострению 3-хуровневых систем, которые меня ещё сильнее убедили в такой необходимости.Было бы конечно странно, если бы они разубедили. Может быть теперь купить и почитать пару книжек, наоборот описывающих плюсы и ньюансы двухзвенных приложений и критикующих 3-х звенки ?

Может. Жду примеры книг, с удовольствием прочту.

ASCRUSвсе решалось стандартными средствами, где в БД помимо самих данных на себе описывала и хранила модель и процессы бизнес-логики, а клиентские приложения только вызывали нужные ХП и занимались своими основными задачами - построением для пользователя удобного и адекватного интерфейса.
Я бы и не задумывался над СП, если бы система была бы не сложной.

DrKonitoСравнивая Контору1 и Контору2 отмечаю следующие факты:
1) 3х звенка тормозила на 30 пользователях, в Конторе2 нормально работают 200 пользователей, несмотря на то что половина мест на жутко неэффективном ацессе.

Спасибо за замечания, очень полезные! По-порядку.
Контора1 делала случайно не 1Сv77 SQL? Эта на такое способна :-)

DrKonito2) Класс разработчиков в Конторе1 был серьезно выше. Им приходилось заниматься действительно нетривиальными проблемами. Но не сказал бы что это является преимуществом 3х звенки :)
Абсолютно согласен. Хочу найти технологию по-проще :-)

DrKonito3) Любого человека который приходил в Контору1 надо было учить фактически с нуля. Первые полгода-год от новых людей было очень мало толку. В Контору2 можно взять студента на 400 баксов с базовым знанием SQL и быстро поставить его в строй.
Не согласен. Когда система грамонтно организована на классовом уровне - как раз в этом случае студенту с улицы легче разобраться, чем копаться в жутком трёхэтажном коде запросов на T-SQL со множествами JOIN и подзапросами.

DrKonitoКстати в несколько другой области лучшим примером толстого клиента является пресловутая 1С-ка. Она тоже по сети гоняет только данные :)
Это её недостаток, но писать в ней код - одно удовольствие. Может это и кошмар для сисадминов, но для программеров - шоколад :-)

Дмитрий Сорокин Обратный пример - самописная учетная система - типичная 2-х звенка, вся логика в хранимых процедурах, MSSQL, 600 одновременных пользователей, 300Gb база, 300млн. проводок, перелезли с 8хXEON700+8Gb RAM на 8xITANIUM2+8Gb RAM , потому что стало подтормаживать - теперь снова летает. Но, конечно, система вылизывалась достаточно долго.
Сервер масштабируется до 24 процессоров и 32Gb RAM, поэтому лет на 10-20 хватит.
При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.
Круто! DCOM, значит отпадает...
Что такое MTS?
...
Рейтинг: 0 / 0
06.10.2005, 10:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33308218
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Простой рабочий
Дмитрий Сорокин Обратный пример - самописная учетная система - типичная 2-х звенка, вся логика в хранимых процедурах, MSSQL, 600 одновременных пользователей, 300Gb база, 300млн. проводок, перелезли с 8хXEON700+8Gb RAM на 8xITANIUM2+8Gb RAM , потому что стало подтормаживать - теперь снова летает. Но, конечно, система вылизывалась достаточно долго.
Сервер масштабируется до 24 процессоров и 32Gb RAM, поэтому лет на 10-20 хватит.
При этом года 3-4 назад vs активно игрались с MTS и DCOM. Переписали основную бизнес-логику по проведению проводок на С++, оформили как DCOM объект под MTS, запустили на тестирование. Может, конечно, у нас руки росли не оттуда, но там, где справлялся 1 MSSQL-сервер нужно было ставить десяток MTS-серверов, чтобы добиться той же производительности при 300 одновременных коннектов.
Круто! DCOM, значит отпадает...
Что такое MTS?

Ну вот, дошли... Народ уже и забыл, что такое Microsoft Transaction Server. А шуму было, а пыли... Лучший сервер приложений, DCOM forever, бесплатно всем сували, даже в дистрибутив NT 4.0 включали! Не прошло и пары лет...
Эх, sic transit gloria mundi... Кто же о нас, бедных, вспомнит через пару лет
...
Рейтинг: 0 / 0
06.10.2005, 11:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33308379
Фотография !!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
!!!
Участник
Простой рабочий ВМоисеевНадо учитывать высокую вероятность нежелательного перехвата конфиденциальной информации посторонними лицами. Вы обязаны криптографически защищать трафик.

А не проще ли шифровать трафик на шлюзах в интернет?Нет уж, будьте последовательны - раз бизнес-логику уносим из сервера БД, то и шифрование тоже в сервер приложений :-))

Простой рабочий !!! Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.И что этот пример показывает, кроме низкого качества проектирования и реализации?

tygra Простой рабочийОт себя приведу пример - модуль проведения документа "Расходня накладная" в 1С:Бухгалтерии 7.7 занимает 1750 строк с использованием процедур и объектов.Это говорит о том, что вы не умеете работать с sql, с ХП и т.д.

Я привёл пример размера кода не самого большого документа, а всего лишь алгоритма формирования бухгалтерских проводок накладной. Меня поразили Ваши ответы. У нас с Вами слишком больша разница в понятии бизнес-логики. Возможно я ошибаюсь, но вы не рабтали с ERP-системами (или хотя бы приближенными к ним).Если я вижу процедуру более 100 строк, я спрашиваю разработчика, в чем причина появления подобной процедуры. Если более 200 строк - требую провести рефакторинг. Если процедура занимает более 1000 строк, то, скорее всего, я предложу разработчику подумать о смене рода деятельности, поскольку программировать он не умеет.

Простой рабочийЧто такое MTS?Дык, сервер приложений, елы-палы
...
Рейтинг: 0 / 0
06.10.2005, 11:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33308435
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Эхххххххх...............

Простой рабочийПочему сервер приложений должен заниматься такими вещами, как изоляция, блокировки, сортировка, джойны, фильтры итп?
Ну если ему этим не заниматься - тогда чем? :))
авторЭто самый главный аргумент против СП. Но почему все ведущие производители ERP-систем используют n-звенную архитектуру и никто не держит бизнес-логику в хп? У меня есть пример одного предприятия, в котором из-за обилия и сложности хп на пределе работал 4-хпроцессорный сервер. Только не говорите, что у них кривая структура БД.
Не скажем. У них просто кривые руки
А вы считаете, что если система любой сложности работает на пределе на 4-х процессорном сервере, то трехзвенка тут уж конечно форы даст, наверное будет работать гораздо лучше на пяти двухпроцессорных нодах плюс тот же самый 4-х процессорный сервер .
Наверное вы не знаете, что существуют большие задачи и под них существуют большие сервера - с 8-и и даже 16-ю процессорами. Это не для вас? Вы боитесь таких серверов?
И кто такие ведущие производители, которые используют n-звенную архитектуру? И как дела у них идут? Неужели вы сравнивали похожие системы на к-с и n-звенке?
авторЕсли Вы не понимаете, в чём разница между обработкой 10^n строк в СУБД и dbf - дальнейшее обсуждение не имеет смысла.
Я не понимаю, причем тут многозвенка :))
авторЯ привёл пример размера кода не самого большого документа, а всего лишь алгоритма формирования бухгалтерских проводок накладной. Меня поразили Ваши ответы. У нас с Вами слишком больша разница в понятии бизнес-логики. Возможно я ошибаюсь, но вы не рабтали с ERP-системами (или хотя бы приближенными к ним).
Наверняка действительно у нас с вами слишком большая разница в понятии БЛ. Давайте определимся, чтобы точно знать, у кого какие понятия.
А если вы считаете, что 1С:Бухгалтерия 7.7 это крутая ERP система, код которой нужно считать за эталон - вы ошибаетесь. Тут на форуме найдется куча людей, бухгалтерия которых работает на порядки лучше 1С. И возможно без 1750 строк кода :))
Хотя с другой стороны, если вы не можете написать то, что в этих 1750 строках кода, в ХП - то чьи проблемы? :)
авторЯ бы и не задумывался над СП, если бы система была бы не сложной.
А у нас всех системы то конечно наипростейшие - вот почему мы в КС можем их запихать, вот оно как! :)
авторНе согласен. Когда система грамонтно организована на классовом уровне - как раз в этом случае студенту с улицы легче разобраться, чем копаться в жутком трёхэтажном коде запросов на T-SQL со множествами JOIN и подзапросами.
Вы точно знаете по опыту или просто sql не знаете? :))
авторЭто её недостаток, но писать в ней код - одно удовольствие. Может это и кошмар для сисадминов, но для программеров - шоколад :-)
Для тех, которые СУБД и sql не знают - а как же! На чем же еще им писать остается?

=======

ЗЫ Хоть отдохнуть тут от работы
-- Tygra's --
...
Рейтинг: 0 / 0
06.10.2005, 11:49
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309016
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Простой рабочий DrKonitoTSQL хорошо знать придется по-любому. А вот если сервер приложений будет делать работу сервера БД (изоляция, блокировки, сортировка, джойны, фильтры итп) то разработчикам кроме собственно бизнес-логики придется задумываться о действительно сложных вещах.

Почему сервер приложений должен заниматься такими вещами, как изоляция, блокировки, сортировка, джойны, фильтры итп ?


Простой рабочий
DrKonito3) Любого человека который приходил в Контору1 надо было учить фактически с нуля. Первые полгода-год от новых людей было очень мало толку. В Контору2 можно взять студента на 400 баксов с базовым знанием SQL и быстро поставить его в строй.
Не согласен. Когда система грамонтно организована на классовом уровне - как раз в этом случае студенту с улицы легче разобраться, чем копаться в жутком трёхэтажном коде запросов на T-SQL со множествами JOIN и подзапросами.


Да это не очевидно сначала :) Вообще это конечно сильно зависит от сервера приложений и решаемых задач. Ну вобщем опять реальная история.
Приложение требовало отчетов и сложных списков на клиенте.
В Конторе1 от тупых внедренцев спрятали "неудобный SQL" и дали им "удобные" объекты типа эээ... Контора1Селект. Заполняешь его свойства, вызываешь метод Экзекуте и тебе выдается объект типа Контора1Лист.
Хорошо это работало только для очень простых запросов. Сложные запросы либо нельзя было сформулировать вообще либо заполнение свойств объекта Контора1Селект представляло из себя головоломку, которую могли решить только гуру проработавшие там хотя бы годик.
Т.к. некоторые запросы не выражались вообще, то все внедренцы очень скоро начинали становится экспертами по структурам данных. Сейчас я знаю как по-умному называются эти приёмы, тогда не знал. Вобщем на ВБА приходилось писать хэш-джойны и мердж-джойны 2-3 массивов, сортировки, группировки итд итп Собирался написать объект балансированного дерева, чтобы делать нестед-луп-джойн, но так и не собрался :)

Вобщем с тех пор у меня есть сильное подозрение, что проблему построения сложных списков аппсервера удовлетворительно могут решить только одним путем- заведением отдельного объекта на каждый такой список\отчет. Под "крышкой" объекта естественно прячется обычный SQL.

Думаю сложные списки это только один из вопросов, которые прямой SQL решает объективно лучше.
Простой рабочий
DrKonitoИз-за нестандартности интерфейса самопального сервера придется самому писать тонны кода, вместо использования стандартных решений.

Это самый главный аргумент против СП. Но почему все ведущие производители ERP-систем используют n-звенную архитектуру и никто не держит бизнес-логику в хп? У меня есть пример одного предприятия, в котором из-за обилия и сложности хп на пределе работал 4-хпроцессорный сервер. Только не говорите, что у них кривая структура БД.
Недавно читал книжку про Enterprise Applications Integration, так там эти системы называли словом stovepipe-application, что в переводе значит - "устанешь интегрироваться" :)

Простой рабочий
Контора1 делала случайно не 1Сv77 SQL? Эта на такое способна :-)Нет
...
Рейтинг: 0 / 0
06.10.2005, 14:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309136
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
DrKonito
Да это не очевидно сначала :) Вообще это конечно сильно зависит от сервера приложений и решаемых задач. Ну вобщем опять реальная история.
Приложение требовало отчетов и сложных списков на клиенте.
В Конторе1 от тупых внедренцев спрятали "неудобный SQL" и дали им "удобные" объекты типа эээ... Контора1Селект. Заполняешь его свойства, вызываешь метод Экзекуте и тебе выдается объект типа Контора1Лист.
Хорошо это работало только для очень простых запросов. Сложные запросы либо нельзя было сформулировать вообще либо заполнение свойств объекта Контора1Селект представляло из себя головоломку, которую могли решить только гуру проработавшие там хотя бы годик.
Т.к. некоторые запросы не выражались вообще, то все внедренцы очень скоро начинали становится экспертами по структурам данных. Сейчас я знаю как по-умному называются эти приёмы, тогда не знал. Вобщем на ВБА приходилось писать хэш-джойны и мердж-джойны 2-3 массивов, сортировки, группировки итд итп Собирался написать объект балансированного дерева, чтобы делать нестед-луп-джойн, но так и не собрался :) О, видно что человек знает проблему не по наслышке. Да, в итоге построение "бизнес логики на сервере приложений" выраждается в что-то такое, о чем вы написали. А ведь как славно все выглядит в учебниках... Контора1Селект.... :)
DrKonito
Вобщем с тех пор у меня есть сильное подозрение, что проблему построения сложных списков аппсервера удовлетворительно могут решить только одним путем- заведением отдельного объекта на каждый такой список\отчет. Под "крышкой" объекта естественно прячется обычный SQL. Да, так и делают, когда надоедать придумывать как же таки "сджоинить" 5 результатов выборок a la Контора1Селект

Простой рабочий
Но почему все ведущие производители ERP-систем используют n-звенную архитектуру и никто не держит бизнес-логику в хп? У меня есть пример одного предприятия, в котором из-за обилия и сложности хп на пределе работал 4-хпроцессорный сервер. Только не говорите, что у них кривая структура БД.
С т.з. теории построения БД у них таки "кривая структура БД". Это раз.
Но она портируемая под разные сервера БД. Это два.
Грубо говоря, отсутствие логики на ХП - это в какой-то мере попытка маркетологов выдать нужду за добродетель.

PS: все больше убеждаюсь, что каждый разработчик бизнес приложений должен хоть раз поучаствовать в проектировании, разработке _и внедрении_ системы с трехзвенной архитектурой и пресловутой "логикой на сервере приложений", чтобы понять чем это грозит и что в итоге получается. На слово юные читатели книг под названием "архитектура коорпоративных систем" не верят, ведь все так здорово описано в умной книжке
...
Рейтинг: 0 / 0
06.10.2005, 14:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309222
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторНедавно читал книжку про Enterprise Applications Integration
DrKonito, поделитесь,
что за книжка, что пишут, какие ощущения?
...
Рейтинг: 0 / 0
06.10.2005, 14:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309297
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Один1PS: все больше убеждаюсь, что каждый разработчик бизнес приложений должен хоть раз поучаствовать в проектировании, разработке _и внедрении_ системы с трехзвенной архитектурой и пресловутой "логикой на сервере приложений", чтобы понять чем это грозит и что в итоге получается. На слово юные читатели книг под названием "архитектура коорпоративных систем" не верят, ведь все так здорово описано в умной книжке
Это точно.
Но также им не мешало бы и поучаствовать в обычных КС проектах - только в путевых, чтобы понять огромную разницу... да и вообще научиться правильно их писать, КС-системы :))

-- Tygra's --
...
Рейтинг: 0 / 0
06.10.2005, 15:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309368
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
tygraЭто точно.
Но также им не мешало бы и поучаствовать в обычных КС проектах - только в путевых, чтобы понять огромную разницу... да и вообще научиться правильно их писать, КС-системы :))
Согласен. Но у меня вот через комнату сидят примеры. Работают с действительно хорошо спроектированным КС. Достаточно удобным и шустрым. А как начинаем обсуждать новый проект, так сразу "только 3 уровня !". Книг начитались, а практического опыта нет. Удалось охладить тем, что 3 уровня - это сейчас не острие науки. Самый писк - service oriented programming (вместо service подставлять language, business, full-circle, короче что угодно). Ушли читать книги.
...
Рейтинг: 0 / 0
06.10.2005, 15:32
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309426
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Совсем затютали простого рабочего:) Все, конечно, правильно. 2-хзвенка, точнее говоря т.н. "терминальные" решения, когда все-все крутится на SQL-сервере, а у клиента лишь создается интерфейс, при хорошей архитектуре данных и вылизанном коде и проще и производительнее и дешевле многозвенки. Но есть один неприятный недостаток SQL-языка - это его "процедурность", что ли. В таком стиле писали в 70-е годы на мэйнфреймах. Вспомните фортран и PL/1:)

Когда я смотрю в Query Analyser на структуру нашей БД - э ато тысячи таблиц, вьюх, хранимых процедур, функций - меня коробит, прямо.

В нормальных языках программирования творческая мысль не стояла на месте -OOP, методы коллективной разработки, контроль версий и т.д. Кто сейчас лабает на чистом C? Или на форте (а класный был язык:). А вот SQL почему-то застыл на месте. Нет, появляются, конечно, всякие новые операторы, вот SQL2005 уже до TRY/CATCH почти дорос:), но, блин, почему нельзя сделать из SQL нормальный объектно-ориентированный язык? Только не надо мне говорить насчет объектно-ориентированных баз данных - это совсем другое. БД пусть остается реляционной - но язык пусть станет нормальным! Кстати, лет 5 назад microsoft громогласно кричал, что вместе с TSQL в SQL2005 можно будет native програмировать на C# или VB.NET. И во что это вылилось? В возможность регистрировать свои сборки на сервере? Блин! Extended SP, только вид сбоку. По моему, это заговор сторонников трехзвенки:)

Может подумать, как из SQL с минимумом изменений сделать что-то вроде OOP языка? Типа SQL++? Да еще и стандартизовать его. Тогда, наверное, никто больше о серверах приложений и не вспомнит:)
...
Рейтинг: 0 / 0
06.10.2005, 15:51
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309446
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Calm авторНедавно читал книжку про Enterprise Applications Integration
DrKonito, поделитесь,
что за книжка, что пишут, какие ощущения?

David S. Linthicum "Enterprise Application Integration"
Publisher: Addison Wesley
First Edition November 05, 1999
ISBN: 0-201-61583-5, 400 pages

Где брал не помню - поищите где-нибудь на http://ebuki.apvs.ru/ и в подобных местах
...
Рейтинг: 0 / 0
06.10.2005, 15:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309476
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Дмитрий СорокинСовсем затютали простого рабочего:) Все, конечно, правильно. 2-хзвенка, точнее говоря т.н. "терминальные" решения, когда все-все крутится на SQL-сервере, а у клиента лишь создается интерфейс, при хорошей архитектуре данных и вылизанном коде и проще и производительнее и дешевле многозвенки. Но есть один неприятный недостаток SQL-языка - это его "процедурность", что ли. В таком стиле писали в 70-е годы на мэйнфреймах. Вспомните фортран и PL/1:)

Когда я смотрю в Query Analyser на структуру нашей БД - э ато тысячи таблиц, вьюх, хранимых процедур, функций - меня коробит, прямо.

В нормальных языках программирования творческая мысль не стояла на месте -OOP, методы коллективной разработки, контроль версий и т.д. Кто сейчас лабает на чистом C? Или на форте (а класный был язык:). А вот SQL почему-то застыл на месте. Нет, появляются, конечно, всякие новые операторы, вот SQL2005 уже до TRY/CATCH почти дорос:), но, блин, почему нельзя сделать из SQL нормальный объектно-ориентированный язык? Только не надо мне говорить насчет объектно-ориентированных баз данных - это совсем другое. БД пусть остается реляционной - но язык пусть станет нормальным! Кстати, лет 5 назад microsoft громогласно кричал, что вместе с TSQL в SQL2005 можно будет native програмировать на C# или VB.NET. И во что это вылилось? В возможность регистрировать свои сборки на сервере? Блин! Extended SP, только вид сбоку. По моему, это заговор сторонников трехзвенки:)

Может подумать, как из SQL с минимумом изменений сделать что-то вроде OOP языка? Типа SQL++? Да еще и стандартизовать его. Тогда, наверное, никто больше о серверах приложений и не вспомнит:)
И что Вы на этом ООП SQL делать собираетесь ? Учитесь запросами и с множествами работать, а не записи лопатить. Тогда окажется, что в ХП и триггерах минимум кода, а динамический SQL дает колоссальные возможности в динамической сборке и выполнения скриптов для задач с изменяющимися версиями алгоритмов, что кстати в ООП языках, не так то легко достигается.

P.S. И спрашивается, зачем по TSQL судить о языках хранимых процедур других РСУБД ? Мало ли, когда там MS догадалась сделать обработку исключений, когда у других все с прошлого века есть - это личные проблемы MS и не нужно под их гребенку равнять остальные РСУБД.
...
Рейтинг: 0 / 0
06.10.2005, 16:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309477
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
Один1 Самый писк - service oriented programming Ушли читать книги.
Эти самые сервисы - тоже трехзвенка вроде - только доступ стандартизирован.
...
Рейтинг: 0 / 0
06.10.2005, 16:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309602
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Дмитрий Сорокин Только не надо мне говорить насчет объектно-ориентированных баз данных - это совсем другое. БД пусть остается реляционной - но язык пусть станет нормальным! Кстати, лет 5 назад microsoft громогласно кричал, что вместе с TSQL в SQL2005 можно будет native програмировать на C# или VB.NET. И во что это вылилось? В возможность регистрировать свои сборки на сервере? Блин! Extended SP, только вид сбоку. По моему, это заговор сторонников трехзвенки:)

Может подумать, как из SQL с минимумом изменений сделать что-то вроде OOP языка? Типа SQL++? Да еще и стандартизовать его. Тогда, наверное, никто больше о серверах приложений и не вспомнит:)

Заговора никакого нет- голая целесообразность:

Для Микрософта это простой расчет:
при двузвенке - 1 сервер БД = 20тыс
при трехзвенке - 1 сервер БД + 10 апп серверов по Win 2000Server = 20 + 20 = 40 тыс
+ стратегические выгоды от перетаскивания разработчиков с относительно космополитичного SQL на проприетарную платформу НЕТ

Для Сана все также очень просто:
при двухзвенке: железка под сервер БД - 1 штука
при трехзвенке: железка под сервер БД + 10 железок под апп-сервера
+ стратегические выгоды от перетаскивания разработчиков на платформу Жаба

Для поставщиков апп-серверов (БЕА) и так все понятно

Про Оракл не скажу- очень далек я от него. Хотя и без оракла денег у первых двух игроков достаточно чтобы как следует пропиарить любые архитектурные решения :)
...
Рейтинг: 0 / 0
06.10.2005, 16:33
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309761
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
DrKonito
Про Оракл не скажу- очень далек я от него. Хотя и без оракла денег у первых двух игроков достаточно чтобы как следует пропиарить любые архитектурные решения :)
Оракл тоже производит свой J2EE сервер, с которым работает их E-Business Suite.
Я бы сюда добавил еще ИБМ с вебсферой и SAP - когда то давно они придумали некий заменитель SQL - ABAP - язык и процессор отчетов (читай - сервер приложений). Делали они это не от хорошей жизни - им надо было слезть с ассемблера:) Тогда, насколько я понимаю, SQL еще не придумали:)

Еще я сказал бы, что сервера приложений выгодны IT-менеджерам - под них можно выбить дополнительные ставки админов и программеров, новое железо и серверное помещение, да и откаты растут:)

Еще она выгодна программерам - изучая ABAP или J2EE повышаешь свою рыночную стоимость:) Все мы видели объявления "ищу программистов на ABAP, оклад - 3 штуки... А кто видел объявления "ищу программистов на SQL за 3 штуки"?

Вообщем - трехзвенка, похоже, выгодна всем, кроме тех, кто на ней работает:) Но кого интересуют такие мелочи:) Так что, господа ретрограды - вперед, к трехзвенке!
...
Рейтинг: 0 / 0
06.10.2005, 17:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309852
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 Дмитрий Сорокин
Вы хоть пример такого ООП-SQL языка предложите - а то я не пойму, об чем вы? Чем вам не нравится sql? Что там такого нельзя сделать?

Не пойму я.

-- Tygra's --
...
Рейтинг: 0 / 0
06.10.2005, 17:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33309871
vkn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkn
Участник
Дмитрий Сорокин
Может подумать, как из SQL с минимумом изменений сделать что-то вроде OOP языка? Типа SQL++? Да еще и стандартизовать его. Тогда, наверное, никто больше о серверах приложений и не вспомнит:)

Есть такой язык, OQL называется. Кое-где даже реализован.
...
Рейтинг: 0 / 0
06.10.2005, 17:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310017
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
tygra2 Дмитрий Сорокин
Вы хоть пример такого ООП-SQL языка предложите - а то я не пойму, об чем вы? Чем вам не нравится sql? Что там такого нельзя сделать?

Не пойму я.

-- Tygra's --

Сделать то на SQL все можно! Сам делаю.
Только возмите к примеру С и С++. Или обычный паскаль и Delphi. А еще лучше С и С#. На ООП-языках можно добиться гораздо более красивой и стройной архитектуры приложения, чем на процедурных.
Можно порассуждать, что тут можно сделать с SQL. У ООП есть 3 важнейшие свойства:
1. Инкапсуляция - код и данные вместе. В SQL уже есть что-то подобное - триггера. Может пойти дальше и привязывать к таблицам хранимые процедуры? Или вообще отказаться от понятия отдельно стоящей процедуры, пусть любая процедура является чьим-то методом (да хоть некоего функционального класса). Кстати, сюда можно будет впихнуть и понятие области видимости - public и private.
2. Полиморфизм - один общий интерфейс объединяет множество процедур, делающих похожие вещи. Ну, к примеру, иметь возможность объединять процедуры с разными форматами вызова под одним названием - сервер пусть сам решает, какую процедуру вызыват - например в зависимости от типов и числа параметров.
3. Неследование. Пусть таблицы и привязанные к ним процедуры (объекты) можно будет использовать как шаблон (или родитель) при создании новых объектов. У этих объектов потом можно будет переопределять свойства (поля) и методы (процедуры)

PS. Прошу ногами не пинать - сам вижу, что бред получается:)
...
Рейтинг: 0 / 0
06.10.2005, 18:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310119
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Все дело в том, что Вы пытаетесь в РСУБД мыслить рамками реализации вот уж действительно процедурных ООП языков. Как говориться, привыкли уже думать известными способами решения. Однако и ООП языки были придуманы не просто так, я для реализации поставленных задач. Так вот если рассматривать именно решение задач, то оказывается, все навороты ООП абсолютно не нужны, просто нужны другие подходы и другой взгляд на решение проблем в абсолютно другом разрезе. ООП изначально предполагает работу с единичными обьектами, SQL изначально работа с множествами. Имея на борту динамический SQL (фактически свой встроенный интрепретируемый язык), можно логику расписывать на уровне метасхемы, которая хранится в табличках и при сборке можно запросами выжать с алгоритмов гораздо больше и гибче, чем реализовывая это на интерфейсах в ООП. Имея представления об организации деревьев на SQL (и тем более, если РСУБД поддерживает рекурсивные запросы), можно элементарно организовать наследование на уровне аттрибутов обьектов. Делать наследование самих таблиц в БД я смысла совершенно не вижу - достаточно сделать главную таблицу и дочерние, которые в зависимости от типа обьекта в записи содержат необходимые для него аттрибуты и использовать LEFT JOIN, функциональность будет та же. В общем список можно долго продолжать - выглядит в SQL совершенно по другому, но по спектру решений ничем не уступает, а даже превосходит ООП в той области, для которой SQL и был создан - обработка данных. Как аналогично функциональные языки так же превосходят ООП в своих областях применения. Я лично не могу сказать, что ООП удобен для обработки данных, он удобен для реализации алгоритмов, здесь даже функциональные языки оказываются предпочительней, где в принципе и SQL в какой то мере можно наверное отнести близким родственником к функциональным языкам с моей точки зрения.
...
Рейтинг: 0 / 0
06.10.2005, 19:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310278
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Простому рабочему.

>А не проще ли шифровать трафик на шлюзах в интернет?
Ссылку на статью, где рассказываю как строю прототип (типовую модель) многозвенки, ранее уже приводил.
Схема передачи данных

клиентские приложения <--> .Net сервис <--> абонентские <--> сервера
(WinForm приложение) поверх IIS ящики приложений

<--> сервер
данных

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

>Работать-то работает, пока эта задача не выйдет за пределы локальной сети.
На каких фактах базируется это заключение? IIS?

С уважением, Владимир.
...
Рейтинг: 0 / 0
06.10.2005, 21:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310405
vialexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vialexis
Гость
Дмитрий СорокинМожет подумать, как из SQL с минимумом изменений сделать что-то вроде OOP языка? Типа SQL++? Да еще и стандартизовать его. Тогда, наверное, никто больше о серверах приложений и не вспомнит:)

Ну не могу не вспомнить старый добрый Visual FoxPro 8.0 :)
Как раз он позиционируется Microsof для написания слоя БЛ (ессно что командой разработки его самого). Кстати, Fox живет и развивается ...
С ностальгией вспоминаю дни работы с VFP (даже наверное, не работы, а учебы).
В общем, вкратце о разработанной мной системе:
В 2002 писал по курсовому проекту для предприятия ЖЭУ систему (прием платежей, расчета квартплаты и пр. бизнес-правила).

Уровень представления был написан на Borland C++ Builder 6.0 - лучшего средства в те времена для построения UI, я считаю, не было.


Уровень бизнес-логики был реализован в in-process automation сервере на VFP 7.0/8.0 beta


Уровень данных на том же VFP. БД с триггерами и ограничениями целостности.

Система реально тестировалась как многопользовательская файл-серверная, т.е. файлы БД лежали на сетевом ресурсе. Здесь могло быть много вариантов физического расположения слоев (при минимальном изменении технологий) и, как следствие, хорошее масштабирование.

В планах было: перевод БД на MS SQL, а уровня БЛ в out-of-process automation server и связи с уровнем представления по DCOM – ну чем не 3-х уровневая архитектура с сервером приложений? Но что мог сделать один студент в насквозь совковой конторе? (Они до сих пор работают в файл-серверной ДОСовской программе).

Конечно, у VFP куча минусов и непоняток, но для написания уровня БЛ я, до сих пор, считаю, что это лучшее решение и причиной тому - самая сладкая синтаксическая парочка SQL+OOP-language (из виденных мною). Сейчас появился Cw (си-омега) .NET с поддержкой SQL, XPath и параллельного программирования (и пр. полезных вещей), но среда разработки интегрированная в VS ещё слишком сырая (редактор XAML-овских форм).

Может, кто использовал VFP для написания уровня БЛ, может с Web-services, или ещё как?
...
Рейтинг: 0 / 0
07.10.2005, 00:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310707
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
vialexis
Конечно, у VFP куча минусов и непоняток, но для написания уровня БЛ я, до сих пор, считаю, что это лучшее решение и причиной тому - самая сладкая синтаксическая парочка SQL+OOP-language (из виденных мною). Сейчас появился Cw (си-омега) .NET с поддержкой SQL, XPath и параллельного программирования (и пр. полезных вещей), но среда разработки интегрированная в VS ещё слишком сырая (редактор XAML-овских форм).

Блин, так как раз таких сладких парочек и хочется избежать! Получается, мы должны использовать сервер приложений только для того, чтобы "объектизировать" данные, хранящиеся в БД и создать красивую архитектуру приложения. Мы сейчас сами занимаемся этим (см. мои посты выше), но ведь не из-за того, что нам заняться нечем! Посмотрите все стандартные рекомендации по созданию среднего слоя: "создайте класс INVOICE, опишите связь этого класса с таблицей INVOICE на уровне get/set, добавьте необходимые методы (чья логика обычно остается в хранимых процедурах) и тд. Почему нельзя это делать уже на уровне сервера БД, где хранятся все данные?
...
Рейтинг: 0 / 0
07.10.2005, 09:47
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310780
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Почему же нельзя? Посмотрите в сторону Cashe.
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
07.10.2005, 10:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310791
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 Дмитрий Сорокин
ASCRUS уже ответил, добавить нечего.

Кстати, этот же пост желательно прочитать vialexis .
Потому как утверждение
авторКонечно, у VFP куча минусов и непоняток, но для написания уровня БЛ я, до сих пор, считаю, что это лучшее решение и причиной тому - самая сладкая синтаксическая парочка SQL+OOP-language (из виденных мною).
именно как раз из-за того, что пытаетесь скрестить ежа и ужа, и не видели ничего другого (наверное), путево реализованного с БД на сервере БД.
Это конечно естественно - я после Фокса тоже не сразу привык разделять систему на клиентскую часть, которая только отображает, и серверную часть, а собственно БД, которая все и делает. Но ничего, прошло - сейчас уже не могу по другому. Никто не заставит держать БЛ на клиенте или каком там звене - бррр.

-- Tygra's --
...
Рейтинг: 0 / 0
07.10.2005, 10:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310809
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторПосмотрите все стандартные рекомендации по созданию среднего слоя: "создайте класс INVOICE, опишите связь этого класса с таблицей INVOICE на уровне get/set, добавьте необходимые методы (чья логика обычно остается в хранимых процедурах) и тд.
Я извиняюсь - вам зачем это?
Зачем вам класс INVOICE и связь этого класса с таблицей INVOICE на уровне get/set ?
Вы без этого жить не можете? Попробуйте - вам понравится :) 50% работы сразу удйет как лишняя - все эти связи и т.д. Зачем вам они? А если не нужны будут - зачем вы определяли?

Что у вас за архитектура приложения?
Зачем вам этот средний слой, который вас заставляет делать вагон ненужной работы?

авторПочему нельзя это делать уже на уровне сервера БД, где хранятся все данные?
Так делайте, кто мешает? Хранимую процедуру уже не умеем написать? :)

-- Tygra's --
...
Рейтинг: 0 / 0
07.10.2005, 10:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310832
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
А где будет ООП, скажем, лет эдак через 10, это еще бабушка надвое сказала...Может быть найдутся те, которые будут относиться к этой концепции, как к дурно понятому Евангелию. Я уже знаю одного такого остряка А вдруг мЫшление приднтся сменить? В том, новом, уже будут доминировать новые "ценности", такие, как матричность и приоритетность в hard-soft-овом контексте...
ЗЫ
А может и загнул я чуток, пятница как-никак
...
Рейтинг: 0 / 0
07.10.2005, 10:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310886
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Люди, в чем вы пытаетесь меня убедить? Что бизнес-логика не должна крутиться на среднем слое? Я и так с этим согласен. В том, что сервера приложений - лишняя трата денег? И с этим согласен. В том, что процедурный подход к архитектуре приложений лучше объектно-ориентированного? Не убедите - все равно не соглашусь. ИМХО: о какой архитектуре приложения можно говорить в случае чистого клиент-серверного приложения (терминалы+сервер БД)? Тысячи таблиц + тысячи хранимых процедур? Или, как тут советовал кто-то - тысячи таблиц + 1 хранимая процедура, создающая динамический SQL код на все случаи жизни?
Нет, я конечно понимаю, что все это будет работать, и работать быстро - у самих все так и работает - но как программисту мне милее ООП с его инкапсуляцией? наследованием и прочими фенечками.
...
Рейтинг: 0 / 0
07.10.2005, 10:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33310916
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторно как программисту мне милее ООП с его инкапсуляцией? наследованием и прочими фенечками.
Вот поэтому то и программисты не должны принимать решения о выборе платформы и используемых технологиях при оценке новых проектов. Слишком часто слова "правильно", "красиво", "милее", "круче" встречаются. Выбирать должен архитектор проекта, ориентируясь на риски, куда входит много чего, кроме вышеперечисленных слов.
...
Рейтинг: 0 / 0
07.10.2005, 10:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33311047
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
ASCRUS авторно как программисту мне милее ООП с его инкапсуляцией? наследованием и прочими фенечками.
Вот поэтому то и программисты не должны принимать решения о выборе платформы и используемых технологиях при оценке новых проектов. Слишком часто слова "правильно", "красиво", "милее", "круче" встречаются. Выбирать должен архитектор проекта, ориентируясь на риски, куда входит много чего, кроме вышеперечисленных слов.

Вообще-то я работаю начальником управления разработки информационных систем в одной ооочень крупной фирме, но в душе все еще считаю себя себя программистом:)
...
Рейтинг: 0 / 0
07.10.2005, 11:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33311305
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Дмитрию Сорокину.
>В том, что сервера приложений - лишняя трата денег? И с этим согласен..

Я нет. Надо научиться их готовить.

С уважением, Владимир.
...
Рейтинг: 0 / 0
07.10.2005, 12:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33311528
Михаил Наседкин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Михаил Наседкин
Гость
Всем привет,

Конкретно по данной теме хочу сообщить, что пользуюсь Apache+mod_perl+SSL+DBI+куча других модулей Perl.
Меня радует простор GNU.
Никого не зову к такому решению, поскольку фактически это равнозначно одиночному плаванию в море.

Всем успехов на своем пути.

Михаил
...
Рейтинг: 0 / 0
07.10.2005, 13:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312253
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Дмитрий СорокинЛюди, в чем вы пытаетесь меня убедить? .... В том, что процедурный подход к архитектуре приложений лучше объектно-ориентированного? Не убедите - все равно не соглашусь.
Вы что-то путаете, уважаемый :)
В архитектуре приложений куда без ООП? Именно оно там и рулит. А вот в архитектуре бизнес-логики - извините, при чем тут ООП? Какой ООП может быть, если у вас таблицы в БД?

Так что вы отделите мух от котлет - и все встанет на свои места.

Клиентская часть - это только интерфейс системы, тут ООП.
Серверная часть - это БЛ системы. Тут ХП.
Все чинно и благородно ((с) фильм "не может быть").

авторИМХО: о какой архитектуре приложения можно говорить в случае чистого клиент-серверного приложения (терминалы+сервер БД)? Тысячи таблиц + тысячи хранимых процедур? Или, как тут советовал кто-то - тысячи таблиц + 1 хранимая процедура, создающая динамический SQL код на все случаи жизни?
Нет, я конечно понимаю, что все это будет работать, и работать быстро - у самих все так и работает - но как программисту мне милее ООП с его инкапсуляцией? наследованием и прочими фенечками.
Так вы сначала попробуйте описать, что вы хотите то от БД? Какого такого оопа? Мы пробовали в топике про ООБД представить идеальную СуперООБД с идеальным языком и т.д. и т.п. После мечтаний оказалось, что ничего не надо - лучше ХП ничего не придумать - ну если только лишний геморрой :)
Так что нужно хоть попробовать представить, что хочется, а потом представить - а надо ли это?
Да я и не пойму - кто вам мешает использовать инкапсуляцию и т.д. в клиентском приложении?
Я не пойму вашей проблемы :)

ВМоисеев>В том, что сервера приложений - лишняя трата денег? И с этим согласен..

Я нет. Надо научиться их готовить.
Мухоморы вот тоже нужно уметь готовить, чтобы употреблять в пищу. А оно надо ? Вокруг столько съедобных грибов


-- Tygra's --
...
Рейтинг: 0 / 0
07.10.2005, 16:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312389
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
tygraВы что-то путаете, уважаемый :)
В архитектуре приложений куда без ООП? Именно оно там и рулит. А вот в архитектуре бизнес-логики - извините, при чем тут ООП? Какой ООП может быть, если у вас таблицы в БД?

Так что вы отделите мух от котлет - и все встанет на свои места.

Клиентская часть - это только интерфейс системы, тут ООП.
Серверная часть - это БЛ системы. Тут ХП.
.

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

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


Поясню. Я хочу при написании бизнес-логики оперировать не таблицами и хранимыми процедурами, а объектами, свойствами и методами. Помимо этого я хочу инкапсулировать бизнес-логику и данные. Плюс, иметь возможность наследовать уже созданную бизнес-логику. И т.д. и т.п. Именно это дает (при всех их недостатках) использование среднего слоя и серверов приложений. Так работают J2EEшные сервера, так позволял работать MTS, так вы работаете с ABAPом в SAPе, к этому призывает микрософт, говоря о веб-сервисах.
...
Рейтинг: 0 / 0
07.10.2005, 17:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312461
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Дмитрий Сорокин tygraВы что-то путаете, уважаемый :)
В архитектуре приложений куда без ООП? Именно оно там и рулит. А вот в архитектуре бизнес-логики - извините, при чем тут ООП? Какой ООП может быть, если у вас таблицы в БД?

Так что вы отделите мух от котлет - и все встанет на свои места.

Клиентская часть - это только интерфейс системы, тут ООП.
Серверная часть - это БЛ системы. Тут ХП.
.

Погодите-ка. А что есть приложение без бизнес-логики? Интерфейс? И ООП нужна для рисования клиентской части? Однако. По моему при написания интерфейса (не создания библиотеки визуализационных элементов, а именно реализации конкретного интерфесса) ООП применима лишь в ограниченном смысле. Конечно можно наследовать уже созданные формы, но покажите мне того, кто это делает:)
Оопс. Оказывается ООП не для наследования форм, создания визуальных и невизуальных повторноиспользуемых компонент создано и все исключительно его по назначению используют - с множествами данных работают Ну круто. А Вы что, правда интерфейсы каждый раз с нуля рисуете или у Вас что то, что имеет ограниченные возможности в этом плане ( Delphi например не сильна ;) ). Зайдите-ка на форум PowerBuilder. Там с иерархии интерфейса построение клиентского приложения и начинается, а вот работу с данными как раз на себя берет DataWindow, который ничего близкого к ООП не имеет, а является аналогом локального хранилища, визуализации и обработки данных (даже со своим внутренним языком), которое получает данные с внешних источников.

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


Поясню. Я хочу при написании бизнес-логики оперировать не таблицами и хранимыми процедурами, а объектами, свойствами и методами. Помимо этого я хочу инкапсулировать бизнес-логику и данные. Плюс, иметь возможность наследовать уже созданную бизнес-логику. И т.д. и т.п. Именно это дает (при всех их недостатках) использование среднего слоя и серверов приложений. Так работают J2EEшные сервера, так позволял работать MTS, так вы работаете с ABAPом в SAPе, к этому призывает микрософт, говоря о веб-сервисах.
Можно глупый вопрос - а зачем Вы хотите оперировать обьектами, свойствами и методами ? И кстати и веб-сервисы уже не только удел 3-х звенок - например в РСУБД ASA9 собственный встроенный веб-сервер и полноценная поддержка веб-сервисов, которые очень удачно и кратко пишутся на языке хранимых процедур, работа с внешними веб-сервисами и полная поддержка XML. Ну и ... зачем тогда ООП ?
...
Рейтинг: 0 / 0
07.10.2005, 17:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312504
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Дмитрий СорокинПоясню. Я хочу при написании бизнес-логики оперировать не таблицами и хранимыми процедурами, а объектами, свойствами и методами. Помимо этого я хочу инкапсулировать бизнес-логику и данные. Плюс, иметь возможность наследовать уже созданную бизнес-логику. И т.д. и т.п. Именно это дает (при всех их недостатках) использование среднего слоя и серверов приложений. Так работают J2EEшные сервера, так позволял работать MTS, так вы работаете с ABAPом в SAPе, к этому призывает микрософт, говоря о веб-сервисах.

Полностью поддерживаю за единственным исключением - если бы подобный механизм был встроен в БД, было бы гораздо интереснее. Какой смысл создавать промежуточный уровень, занимающийся маппингом реляционных данных на объекты и обратно, если можно было бы при помощи запросов, подобных SQL получать из базы данных типизированные объекты и коллекции.

tygraВы что-то путаете, уважаемый :)
В архитектуре приложений куда без ООП? Именно оно там и рулит. А вот в архитектуре бизнес-логики - извините, при чем тут ООП? Какой ООП может быть, если у вас таблицы в БД?
Так что вы отделите мух от котлет - и все встанет на свои места.
Клиентская часть - это только интерфейс системы, тут ООП.
Серверная часть - это БЛ системы. Тут ХП.

Узко мыслите уважаемый. Ну напишите вы ХП, а как повторно использовать вашу бизнес-логику? Где наследование, инкапсуляция, полиморфизм на уровне ХП? Не боитесь завязнуть в бесконечных переделках половины ваших ХП при небольшом изменении логики системы?
Даже просто поддерживать подобные базы неудобно. На поиск нужной ХП в списке из 1500 штук мне требуется довольно длительное время.
Разрабатывать и затем развивать и поддерживать системы, где вся логика в ХП - очень геморное занятие по сравнению с поддержкой аналогичной по объему системы, написанной на нормальном ОО-языке.
To ASCRUS:
Оопс. То есть вы отрицаете возможность использования ОО-подхода при реализации бизнес-логики? ООП предназначено только для построения пользовательского интерфейса? Ну и новости... Ну что же, флаг вам в руки, пишите все на ХП. Это тоже вариант, при условии, что логика достаточно простая и система не очень большая. При усложнении логики и увеличении размера системы начинают проявляться проблемы такого подхода. Ну собственно, можно здесь развести дискуссию о том, чем ОО-язык лучше процедурного, каким является процедурное расширение SQL, на котором собственно и пишутся ХП. Только зачем, это и так много раз мусолилось еще лет 10-20 назад.
...
Рейтинг: 0 / 0
07.10.2005, 17:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312518
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Дмитрий СорокинПоясню. Я хочу при написании бизнес-логики оперировать не таблицами и хранимыми процедурами, а объектами, свойствами и методами. Помимо этого я хочу инкапсулировать бизнес-логику и данные. Плюс, иметь возможность наследовать уже созданную бизнес-логику. И т.д. и т.п. Именно это дает (при всех их недостатках) использование среднего слоя и серверов приложений. Так работают J2EEшные сервера, так позволял работать MTS, так вы работаете с ABAPом в SAPе, к этому призывает микрософт, говоря о веб-сервисах.Очень хорошее желание. И все очень хорошо бегает НО до определенного предела.

У меня сейчас система на чистых SQL-запросах + ХП из них же очень так хорошо прогибается на больших объемах.
До меня работали на C-диез - тормоз был совсем чугунный (после была переписана вся система).

Вывод: с одиночными данными хорошо работать на обектах, но вот таблички гонять по 10 млн. записей через объекты уже не получится. ПРИХОДИТСЯ применять SQL потома что он быстрее .
...
Рейтинг: 0 / 0
07.10.2005, 18:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312530
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Ну давайте уважаемые адепты 3-х звенок спустимся наконец на землю и на конкретных примерах от вас услышим, что же это за бизнес-логика такая у вас сложная, что она выльется в тысячи хранимых процедур с большим кол-вом кода, да еще который из за изменения ТЗ весь почему то лопатить придется ? У меня вот никак не получается придумать - и расчет зп на ХП нормальный и расчет коммуналки не хуже, и расчет по графам потребления энергии для РАО на ХП и даже свой компилятор хранимых процедур на базе HTML макетов, которые дальше для веб-сервисов генерили по макетам HTML (можно сказать в чем то аналог PHP/ASP, но с поддержкой еще макросов, где в качестве встроенного языка был сам язык хранимых процедур) ... причем писал я этот компилятор ... как раз на ХП (их меньше 10 штучек получилось и кода тоже много не наблюдалось). В чем же тогда дело ? А как в бедных функиональных языках без ООП живут, ну просто ума не приложу
...
Рейтинг: 0 / 0
07.10.2005, 18:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312558
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
VoDA: а вы гоняете 10 млн записей на промежуточный слой? или на клиента?
А смысл? Такую логику, которая требует перелопатить 10 млн записей проще все же реализовать в базе данных просто потому что гонять такие объемы данных куда бы то ни было накладно.
Собственно то что я говорил про ОО-подход не отменяет использование ХП ни в коей мере. Я не говорю о том случае, когда мы на ОО-языке начнаем построчно обрабатывать данные вместо того, чтобы использовать возможности SQL. Просто ОО-подход в данный момент лучше всего подходит для структурирования всего приложения, и бизнес-логика не исключение. Да, в конечном итоге большая ее часть будет реализована в ХП. Но опять же лучше написать небольшое количество более-менее универсальных ХП и потом использовать их из ОО-языка в промежуточном слое, чем на каждый чих писать свою ХП, поддерживать которые потом совершенно неудобно.
...
Рейтинг: 0 / 0
07.10.2005, 18:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312578
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUS: Ну давайте возьмем любую ERP-систему средней сложности в целом. Как вы думаете, какая там должна быть бизнес-логика по объему? Попробуйте прикинуть количество операций, который выполняет эта система. И скажите, почему практически все эти системы работают в 3-х и более звенном режиме? Исключительно из дани моде или все же по каким-то другим причинам?
...
Рейтинг: 0 / 0
07.10.2005, 18:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312582
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Да, пару слов насчет бедных функциональных языков: практически все современный диалекты функциональных языков имеют ОО-возможности. Я уже не говорю про ОО-языки с некоторыми чертами функциональных, которых тоже навалом. В последнее время вообще идет тенденция к сближению этих двух подходов.
...
Рейтинг: 0 / 0
07.10.2005, 18:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312592
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
2 VladiCh
В проектировании, разработке и поддержке сколькИх 3-х уровневых ERP систем с БЛ на среднем уровне лично вы принимали участие ?
...
Рейтинг: 0 / 0
07.10.2005, 18:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312631
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
В проектировании и разработке собственной системы принимал участие (это скорее некий framework, на котором пока реализован склад, CRM + workflow, CMS. Просто стояла задача сделать систему максимально расширяемой, которая легко могла бы масштабироваться и обрастать другой функциональностью. Поэтому изучал архитектуру других систем, некоторые из которых относятся к ERP ли же "почти ERP", некоторые к другим классам систем (CRM, документооборот).
Был опыт доработки и поддержки самописной 2-х звенной системы, впечатления от этого остались не очень хорошие.
...
Рейтинг: 0 / 0
07.10.2005, 19:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312658
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
VladiChВ проектировании и разработке собственной системы принимал участие (это скорее некий framework, на котором пока реализован склад, CRM + workflow, CMS. Просто стояла задача сделать систему максимально расширяемой, которая легко могла бы масштабироваться и обрастать другой функциональностью. Поэтому изучал архитектуру других систем, некоторые из которых относятся к ERP ли же "почти ERP", некоторые к другим классам систем (CRM, документооборот).
Был опыт доработки и поддержки самописной 2-х звенной системы, впечатления от этого остались не очень хорошие. Понятно, спасибо за честный ответ.
...
Рейтинг: 0 / 0
07.10.2005, 19:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312690
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
VoDAУ меня сейчас система на чистых SQL-запросах + ХП из них же очень так хорошо прогибается на больших объемах.
До меня работали на C-диез - тормоз был совсем чугунный (после была переписана вся система).

Вывод: с одиночными данными хорошо работать на обектах, но вот таблички гонять по 10 млн. записей через объекты уже не получится. ПРИХОДИТСЯ применять SQL потома что он быстрее .

Черт, опять меня не понимают!
Попробую пояснить еще раз. Наша информационная система существует уже 10 лет. Это чистая 2х-звенка - вся логика в ХП. У системы есть вылизанное и много раз рефакторенное ядро. Вокруг ядра за 10 лет накопилось огромное количество логики, писавшееся множеством программистов. Для написания интерфейсов использовалось все - начиная от Access 2.0 кончая С++, Delphi и VB. За эти 10 лет система превратилась в монстра, состоящего из тысяч таблиц, процедур, вьюх и тп., который мы наконец решили полностью рефакторить. Основная причина рефакторинга то, что поддерживать систему, а тем более вносить в нее изменения становится все сложнее.

Суть рефакторинга состоит в создании классов-оберток для объектов БД. Упрощенно говоря таблицы - это классы, поля - свойства, хранимые процедуры - методы. Классы создаются динамически на основе метаданных. Помимо классов создается и интерфейс - тоже на основе метаданных. Нет необходимости переписывать имеющуюся бизнес-логику - достаточно описать ее в метаданных. Посмотрите мои предыдущие посты в этой ветке - там про это написано. Я в одном из постов приаттачил описание библиотеки, создающей классы на основе описания БД - посмотрите, кому интересно.

То, что мы делаем, должна, с моей точки зрения, мочь сама БД. Если бы механизмы ООП были бы встроены в БД изначально, мы бы с самого начала избежали многих проблем.
...
Рейтинг: 0 / 0
07.10.2005, 20:13
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33312748
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
Дмитрий Сорокин Основная причина рефакторинга то, что поддерживать систему, а тем более вносить в нее изменения становится все сложнее.

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

Используя которую (ВНЕШНЕЕ объектное описание) - можно было бы создавать шаблоны запросов к базе (без мучительных поисков - что означает та или иная таблица, вьюха).
...
Рейтинг: 0 / 0
07.10.2005, 21:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313104
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VladiChУзко мыслите уважаемый. Ну напишите вы ХП, а как повторно использовать вашу бизнес-логику? Где наследование, инкапсуляция, полиморфизм на уровне ХП? Не боитесь завязнуть в бесконечных переделках половины ваших ХП при небольшом изменении логики системы?
Очень сильно зависит от того, насколько прямые ручки были у проектировщика.
VladiChДаже просто поддерживать подобные базы неудобно. На поиск нужной ХП в списке из 1500 штук мне требуется довольно длительное время.желательно грамотно именовать ХП впрочем как и классы, так что это относится и к ООП.
(поиск нужного класса из 1500 это - забавно наверное).
VladiChРазрабатывать и затем развивать и поддерживать системы, где вся логика в ХП - очень геморное занятие по сравнению с поддержкой аналогичной по объему системы, написанной на нормальном ОО-языке.Голословно.
VladiChVoDA: а вы гоняете 10 млн записей на промежуточный слой? или на клиента?
А смысл? Такую логику, которая требует перелопатить 10 млн записей проще все же реализовать в базе данных просто потому что гонять такие объемы данных куда бы то ни было накладно.Пример есть исхходная база - DBF или Access, нужно данные из нее добавить в БД с идентификацией нужных сущьностей и т.п. Раньше писали приложение, которое являлось клиентом для БД. Оно обрабатывало и загоняло данные на сервер.
Из-за диких тормозов переделали и сейчас идет обработка только на сервере БД
VladiChСобственно то что я говорил про ОО-подход не отменяет использование ХП ни в коей мере. Я не говорю о том случае, когда мы на ОО-языке начнаем построчно обрабатывать данные вместо того, чтобы использовать возможности SQL. Просто ОО-подход в данный момент лучше всего подходит для структурирования всего приложения, и бизнес-логика не исключение. Да, в конечном итоге большая ее часть будет реализована в ХП. Но опять же лучше написать небольшое количество более-менее универсальных ХП и потом использовать их из ОО-языка в промежуточном слое, чем на каждый чих писать свою ХП, поддерживать которые потом совершенно неудобно.Универсальные ХП могут оказаться большим злом для системы.

Вывод (для себя): Я соглашусь, но только добавлю, что везде где идет работа с массивами данных стоит использовать SQL, а на единичных объектах - ООП.
...
Рейтинг: 0 / 0
08.10.2005, 17:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313107
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Дмитрий Сорокин
Черт, опять меня не понимают!
Зато стараются.
Дмитрий Сорокин
Суть рефакторинга состоит в создании классов-оберток для объектов БД. Упрощенно говоря таблицы - это классы, поля - свойства, хранимые процедуры - методы. Классы создаются динамически на основе метаданных. Помимо классов создается и интерфейс - тоже на основе метаданных. Нет необходимости переписывать имеющуюся бизнес-логику - достаточно описать ее в метаданных. Посмотрите мои предыдущие посты в этой ветке - там про это написано. Я в одном из постов приаттачил описание библиотеки, создающей классы на основе описания БД - посмотрите, кому интересно. а не будет ли проше переписать ядро, вместо написания оберток к ТОМУ, что у вас есть. Или опять не понял.
Дмитрий СорокинТо, что мы делаем, должна, с моей точки зрения, мочь сама БД. Если бы механизмы ООП были бы встроены в БД изначально, мы бы с самого начала избежали многих проблем.Объективная реальность такова, что этого нет. Почему нет это другой вопрос, но решать вам надо не его.
С Уважением, VoDA
...
Рейтинг: 0 / 0
08.10.2005, 17:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313118
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VoDA проше читай проще

т.е еще раз вы пишете обертки к:
Дмитрий СорокинЗа эти 10 лет система превратилась в монстра, состоящего из тысяч таблиц, процедур, вьюх и тп., который мы наконец решили полностью рефакторить
ИМХО это хм... не обычно. Очень...
...
Рейтинг: 0 / 0
08.10.2005, 17:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313144
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
VoDAа не будет ли проше переписать ядро, вместо написания оберток к ТОМУ, что у вас есть. Или опять не понял.

Эх, ядро то у нас хорошее, на нем то все 10 лет и держится:) Но ведь бизнес-логика то не в ядре, а в конкретных модулях. Типа, есть у вас документ - накладная. Это набор таблиц - голова, деталировка и т.п. Есть набор хранимых процедур, связанных с накладной, в которых лежит бизнес-логика накладной. Все это дело описывается в метаданных, на основе чего создается класс "Накладная". Сам класс является лишь интерфейсом к таблицам и хранимым процедурам. Но теперь программисту нет нужды работать с таблицами и процедурами - он работает с классом и методами. Плюс - все преимущества ООП - наследование, полиморфизм и т.д.
...
Рейтинг: 0 / 0
08.10.2005, 18:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313168
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Но если все таки все хранится в конкретных таблицах, ХП и триггерах то на кой спрашивается для класса обертки наследование, чего он будет там будет спрашивается расширять то ? И не понимаю я, чем доступ к классам для разработчика лучше доступа через SQL к таблицам и ХП ? Отмазы типа "их много" не принимаются - при граммотной проектировке можно и стандарт именования соблюдать и по пакетам или овнерам разделить в БД, в зависимости от возможностей сервера. Так что пока для меня утверждение - лучше работать с классами, чем напрямую с обьектами БД звучит странно - я в своей жизни вынес для себя самое главное правило - чем проще система и чем меньше кода при реализации нужной функциональности, тем она лучше. Ваши классы-обертки усложняют систему и вводят новое кол-во кода, что противоречит моим взглядам на эффективные системы.
...
Рейтинг: 0 / 0
08.10.2005, 18:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313218
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
2ACRUS:
Давайте представим, что существует вот такая СУБД (объектно-реляционная):
1. Возможность создавать классы, соответствующие данным
2. Методы классов можно писать на языке а-ля С# + SQL
3. Наследование автоматически включает хранимые [Stored] поля базовых классов, а таблица задается "верхним" классом (для примера ниже все документы, имеющие в базовом списке DocumentBase будут иметь поля Number и Status, а кто унаследован от DocumentSign - Number, Status и SignedBy).


Тогда для вымышленной системы документооборота можно иметь следующую иерархию:
class DocumentBase //базовые свойства документов
{
[Stored]
string Number;
[Stored]
int Status;
......
}

class DocumentSign : DocumentBase //базовый класс для документов, треб.
{ // подпись

[Stored]
SignedBy: CPerson;

method Sign( person : CPerson)
{
SignedBy = person;
Save();
}
}
......

Тогда в коде приложения на РМ, где происходит операция подписи документа, независимо от типа документа ( накладная, заявление по собств. желанию ....)
выполняется код:

(DocumentSign)currentDocument.Sign( currentUser);


Хотелось бы увидеть, как может выглядеть структура данных + ХП для аналогичный случая на обычной системе КС + РСУБД.

P.S. Прошу воспринимать как нормальную дискуссию - действительно интересно, какие есть способы улучшить дизайн КС системы, не изобретая объектные обертки и движки СУБД.
...
Рейтинг: 0 / 0
08.10.2005, 20:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313238
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Имхо дискуссия сильно сместилась от конкретики в сторону философии и вкусовых предпочтений участников. Предлагаю посмотреть на вопрос не чисто с точки зрения программизма.

ВМоисеевДмитрию Сорокину.
>В том, что сервера приложений - лишняя трата денег? И с этим согласен..
Я нет. Надо научиться их готовить.
С уважением, Владимир.Владимир, как наиболее последовательному защитнику многозвенки,
позвольте задать несколько конкретных вопросов к вам о вашей системе.

1)Какова была трудоемкость создания вашей системы в человеко-годах?

2)Что представляет из себя поддержка вашей системы?
2.1) Кто её осуществляет: вы, коллеги, отдел техподдержки, сотрудники заказчика?
2.2) Каков потребный уровень квалификации для осуществления техподдержки?
2.3) Кто и при помощи каких инструментов осуществляет аудит системы, мониторинг показателей её производительности?
2.4) Что представляет из себя система безопасности вашей системы? Как туда заводятся пользователи и как назначаются им права? Интегрирована ли она с другими системами безопасности на вашем предприятии?
2.5) Какой объем данных порождается системой за месяц?
2.6) Каково среднее время безостановочной работы вашей системы?

3)Процесс внесения измений в систему.
3.1)Какое количество изменений приходится реализовывать в вашей системе в течении месяца?
3.2)Кто осуществляет эти изменения? Вы, коллеги, сотрудники заказчика?
3.3)Как происходит деплоймент изменений? Каждый пользователь должен обновить клиента и каждый апп-сервер должен быть остановлен и обновлен?
3.4)Какие инструменты\приемы вы используете при поиске причин нетривиальных ошибок в вашей системе?

4) Интеграция с другими системами
4.1) С какими сторонними системами ваша система интегрирована сейчас и каким образом?
4.2) Какие перспективы в области интеграции вы видите для вашей системы?
4.3) Как вы реализуете пакетные задания в вашей системе? (Я имею в виду некие автоматизированные задания по расписанию, не требующие участия пользователя)
4.4) Каким способом вы генерируете в вашей системе отчеты?

5) Как вы видите перспективу развития вашей системы скажем на 5 лет вперед?
5.1) Какой вы видите перспективу технологий использованных вами сейчас при разработке системы?
5.2) Как повлияет моральное устаревание использованных вами технологий на возможность использования системы?
...
Рейтинг: 0 / 0
08.10.2005, 21:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313240
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
В принципе хотелось бы услышать ответы на вопросы из моего предыдущего поста от любого сторонника многозвенки.
...
Рейтинг: 0 / 0
08.10.2005, 21:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313260
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
ASCRUS авторно как программисту мне милее ООП с его инкапсуляцией? наследованием и прочими фенечками.
Вот поэтому то и программисты не должны принимать решения о выборе платформы и используемых технологиях при оценке новых проектов. Слишком часто слова "правильно", "красиво", "милее", "круче" встречаются. Выбирать должен архитектор проекта, ориентируясь на риски, куда входит много чего, кроме вышеперечисленных слов.В принципе, согласен, но вот Туполев, в свое время, глядя на чертеж самолета иногда говорил - "Не полетит! Некрасивый", и всегда оказывался прав. Красивые архитектурные решения, как правило, обеспечивают не только удобную реализацию, но и создают условия для последующего сопровождения.
Так что "правильно" и "красиво" - это тоже вполне достойные критерии, которые тоже вносят свой вклад в успех проекта.
...
Рейтинг: 0 / 0
08.10.2005, 22:33
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313421
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito.

Спасибо за перенос акцентов. Меня интересуют не споры, что лучше двухзвенка-многозвенка, а варинты построения реальных многозвенных систем.

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

Предпоследний вариант был для DCOM, но три года назад узнал о возможностях .Net и все свои знания и опыт попытался воплотить в при построении реальной системы в данной среде. Отчет, о то что и как получилось опубликовано здесь (повторяюсь): http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx
(первая и третья редакции). Если интересует текущее состояние проекта, могу переслать пятую редакции статьи.


С уважением, Владимир.
...
Рейтинг: 0 / 0
09.10.2005, 12:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313424
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito.

Спасибо за перенос акцентов. Меня интересуют не споры, что лучше двухзвенка-многозвенка, а варинты построения реальных многозвенных систем.

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

Предпоследний вариант был для DCOM, но три года назад узнал о возможностях .Net и все свои знания и опыт попытался воплотить в при построении реальной системы в данной среде. Отчет, о то что и как получилось опубликовано здесь (повторяюсь): http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx
(первая и третья редакции). Если интересует текущее состояние проекта, могу переслать пятую редакции статьи.


С уважением, Владимир.
...
Рейтинг: 0 / 0
09.10.2005, 12:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313425
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito.

Спасибо за перенос акцентов. Меня интересуют не споры, что лучше двухзвенка-многозвенка, а варинты построения реальных многозвенных систем.

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

Предпоследний вариант был для DCOM, но три года назад узнал о возможностях .Net и все свои знания и опыт попытался воплотить в при построении реальной системы в данной среде. Отчет, о то что и как получилось опубликовано здесь (повторяюсь): http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx
(первая и третья редакции). Если интересует текущее состояние проекта, могу переслать пятую редакции статьи.


С уважением, Владимир.
...
Рейтинг: 0 / 0
09.10.2005, 12:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313629
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUSНо если все таки все хранится в конкретных таблицах, ХП и триггерах то на кой спрашивается для класса обертки наследование, чего он будет там будет спрашивается расширять то ? И не понимаю я, чем доступ к классам для разработчика лучше доступа через SQL к таблицам и ХП ? Отмазы типа "их много" не принимаются - при граммотной проектировке можно и стандарт именования соблюдать и по пакетам или овнерам разделить в БД, в зависимости от возможностей сервера.


Тут уже выше г-н ООП привел правильный пример. Я могу еще добавить следующее:
иерархия таблиц в системе может быть организована параллельно иерархии классов, наследование на уровне БД может быть реализовано разными способами, чаще всего просто отношением 1 к 1. В результате мы получаем более абстрагированный от сущностей код, который может работать не с одной сущностью, а с иерархией. Помимо абстракций наследования ООП позволяет много других вещей организовывать, невозможных в обычном процедурном программировании, почитайте в конце концов про паттерны проектирования для любого ОО-языка. Да, это действительно больше актуально для других областей, где требования к гибкости и повторному использованию кода больше, но и для бизнес-логики это актуально в случае более-менее большой и сложной (в смысле не сложных алгоритмов, а сложных и/или многочисленных связей между компонентами. Хотя и для алгоритмически сложной задачи ОО-подход актуален, хотя и в меньшей степени) системы. Если взять отдельную, не очень большую, пусть даже алгоритмически сложную задачу типа расчета зарплаты, о которой вы писали, то такой подход может и не понадобиться, или же выигрыш от него будет минимальным. Да, классы обертки в какой-то мере усложняют в систему на начальном этапе, но дают бОльшую гибкость и больше возможностей для повторного использования кода, в конечном итоге при достижении системой определенного размера они начинают наоборот упрощать жизнь, и приводят в результате к меньшему количеству кода, который легче поддерживать.

По поводу стандартов именования и разделения по пакетам и овнерам – это тоже не панацея, по крайней мере для MSSQL. Тут нет пакетов, а разделение по овнерам не особо поможет. Количество – это разумеется не главная причина, по которой не стоит строить серверную часть только на ХП, просто одна из причин, которые усложняют жизнь разработчику и тому, кто потом занимается сопровождением системы.

VoDAжелательно грамотно именовать ХП впрочем как и классы, так что это относится и к ООП.
(поиск нужного класса из 1500 это - забавно наверное).


Классов в системе будет на порядок меньше, чем ХП в соответствующей по функциональности базе. Да и потом, иерархию классов, разбиение по namespace и сам код я могу структурировать как угодно, в базе же такого не сделать. Правильно именовать объекты – это само собой, но одно это правило проблемы не решает.

Вообще разговор перешел в интересную плоскость – не о том, лучше ли многозвенка двухзвенки, а о том, нужна ли объектная прослойка между СУБД и клиентом. По результатам этого обсуждения у меня сложилось впечатление, что адепты двухзвенок и отказа от объектной прослойки просто занимаются разработкой исключительно серверной части, причем с бОльшим упором на базу данных (вернее база данных и является единственной серверной частью), проблемы разработки клиента к этой серверной части от них немного в стороне находятся. Советую поднабраться опыта разработки клиентов и промежуточного слоя на любом ОО-языке, например веб-приложений или веб-сервисов – промежуточный слой в чистом виде. Тогда вопросов уровня “что лучше, ХП или классы”, поубавится.
...
Рейтинг: 0 / 0
09.10.2005, 17:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313795
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторВообще разговор перешел в интересную плоскость – не о том, лучше ли многозвенка двухзвенки, а о том, нужна ли объектная прослойка между СУБД и клиентом. По результатам этого обсуждения у меня сложилось впечатление, что адепты двухзвенок и отказа от объектной прослойки просто занимаются разработкой исключительно серверной части, причем с бОльшим упором на базу данных (вернее база данных и является единственной серверной частью), проблемы разработки клиента к этой серверной части от них немного в стороне находятся. Советую поднабраться опыта разработки клиентов и промежуточного слоя на любом ОО-языке, например веб-приложений или веб-сервисов – промежуточный слой в чистом виде. Тогда вопросов уровня “что лучше, ХП или классы”, поубавится.
Не очень понятен этот абзац. Если Вы намекаете, что тут собрались исключительно теоретики и проектировщики БД, то смею Вас уверить, предложение Ваше "поднабраться опыта" не выглядит заманчивым - с 90-ого года я слишком много поднабрался опыта начиная с TP3, Clipper, меняя взгляды в сторону ООП на TP5.5, а так же потом всякие FoxPro, Paradox, Delphi, Java ... Так что и свои движки БД делал и с файл-серверными системами плотно работал, даже 3-х звенкой в конце 90-ых баловался через DCOM. Куда уж больше опыта. Лично сейчас я предпочитаю использовать ООП по назначению - рисовать иерархию форм, визуальные компоненты и прочие вещи для интерфейса клиента, парсеры, интерпретаторы и прочие интересные для ООП вещи, руководствуясь простой истиной для проектов с БД - чем меньше клиентского кода, тем меньше ошибок в нем сделают кодеры. А вот что то рисовать на алгоритмических языках, ООП они или процедурные или еще какие - желания никакого абсолютно нет, представляется мне это неэффективным, неудобным и даже скучным. И по многим, голосующим здесь за бизнес-логику на РСУБД могу сказать тоже самое, путь они прошли долгий, пока поменяли мировозрение и выбрали такую схему работы, что частенько давалось тяжело.
...
Рейтинг: 0 / 0
09.10.2005, 23:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33313940
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
Благодаря Дмитрию Сорокину обсуждение перешло именно в то русло, которое и сподвигло меня задуматься о сервере приложений, а последний пост от VladiCh должно расставить точки над и.
Я уже один раз осмелился высказать, что БЛ разделиввшихся на две стороны (использование ООП) приницпиально различаются. И здесь не должно быть навязывание друг другу того или иного подхода. В случае биллингов (то бишь расчетов - з/п или ещё чего) этот средий слой с ОО по большому счету не нужен. Если же вы строите ERP-систему, где применяется план счетов со множеством аналитик, где на каждый документ огромное число правил - то сопровождение такой двухуровневой системы очень сложно (что в данный момент у нас в организации и происходит), классы намного бы упростили задачу разработки и сопровождения. Выход я пока видел один - сервер приложений. Здесь Дмитрий предложил обёртки, но хотелось бы это глянуть вживую, не совсем понятно.
И вообще мне не понятна проблема с СП. Почему ведущие приозводители не хотят его создать по принципу и подобию СУБД? Что нужно для функционирования СП?
1) Запустить на сервере службу с СП (как запускается, допустим, MSSQLServer)
2) Установить соединение с СП (аналогично соединению с MSSQLSever)
3) Запускать процессы бизнеc-логики аналогично запуску процессов на MSSQLServer
3) Обмен с СП происходит не на уровне запросов и результатов выборки, а на уровне объектов (документ, справочник, отчёт и т.д.).
Почему СП должен тормозить? Почему никто не говорит, что СУБД тормозит?
Не спорю, что мы проигрываем в скорости из-за дополнительного звена, но выигрываем в удобности поддержки, а сл-но в скорости изменения БЛ, а также уменьшения возникаемых ошибок при изменении.
...
Рейтинг: 0 / 0
10.10.2005, 08:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314006
a40
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a40
Участник
авторПочему СП должен тормозить? Почему никто не говорит, что СУБД тормозит?

Ну как бы разные порядки величины торможения. На фоне СП тормоза СУБД малозаметны.
...
Рейтинг: 0 / 0
10.10.2005, 09:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314153
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЕсли же вы строите ERP-систему, где применяется план счетов со множеством аналитик, где на каждый документ огромное число правил - то сопровождение такой двухуровневой системы очень сложно (что в данный момент у нас в организации и происходит), классы намного бы упростили задачу разработки и сопровождения. Выход я пока видел один - сервер приложений.
У меня проект под департамент социальных выплат для крупного холдинга - поддерживается куча аналитических схем (многоуровневых деревьев) планового и фактического учета выплат, настраиваемые правила по документам - от контроля необходимости заполнения различных аттрибутов документов до финансового мониторинга, системы заявок и статусов фактических выплат, аналитики и прочее. Все это еще обвязано в схему работы узлов, где есть дерево с консолидированной вершиной (сам холдинг) и многоуровневым обеспечением хранения, доставки и работы на удаленных узлах (серверах) с помощью оффлайн репликаций, единым централизованным управлением как серверами, так и правами пользователей (вплоть до того, что пользователь имеющий права на нужные узлы спокойно со своим логином и паролем может разьезжать между ними и работать/администрировать с системой). Все это реализовано стандартными средствами: хранимые процедуры и триггера, дополнительные скрипты в таблицах (text), динамический SQL, репликация. Кода вообще копейки, все легко расширяется и интегрируется с другими системами, откуда могут браться дополнительные данные (с той же зп или ERP). Естественно на клиентской части созданы удобные средства управления и администрирования логики проекта, большая часть - это вообще собственные системные обьекты, отработанные не один год, работающие во всех наших проектах и организованные по модульной системе, проекты пишутся командой, соответствующе изменения служебных обьектов БД или иерархий классов в клиентской части идут через систему контроля версий и спокойно собираются для остальных проектов. Никакого 3-его звена, минимальное кол-во кода и достаточно большая гибкость, универсальность и легкость. Есть одна оговорка - на MSSQL все этого бы не получилось в том полном обьеме, что у нас есть. На ASA или Oracle это нормально можно организовать (на ASA правда по легче, для Oracle придется попыхтеть). Так же сейчас у нас в предварительных проектах лежит система документооборота и система организации интернет продаж с требованиями реализации универсальных пользовательских механизмов, позволяющих на уровне блок схем описывать движение документов и правила продаж товаров с возможностью дополнительной логики (например проводимые акции, подарки и прочее). Самое интересное - если эти проекты будут утверждены для разработки, я даже задумываться не буду - не вижу ни одного препятствия для того, чтобы всю эту логику реализовать средствами БД, причем я даже сразу знаю, как. Так может быть просто стоит задуматься о смене сервера, может быть клиентской части и повышении квалификации, чем переходить на ООП, который по любому для РСУБД, что кривой костыль и мешать парадигмы, где все равно от SQL так или иначе никуда не денешься и обвязка данных обьектами все равно не позволит полностью увести приложение на обьектный уровень, а значит какой в этом толк, если все равно те же отчетники будут требовать SQL, расчеты над множествами данных быстрее работать на ХП и прочее.

P.S. Да - я еще никак не понимаю акцента на клиентские части. Неужели разово нарисовать иерархию интерфейсной части, отработать ее по самое не хочу, купить и доработать универсальные компоненты доступа и визуализации данных через SQL сложнее, чем писать с нуля свою трехзвенку, а значит по любому что то свое лепить с нуля. Про универсальных саморазворачивающихся клиентов можно забыть - легче мышкой накидать новую формочку, причем даже лучше будет не формочку-класс, а формочку встроенного в клиентское приложение какого либо скриптового языка с визуальным дизайнером, благо их навалом, чем пытаться автоматически их генерить, ущемляя удобство интерфейса и возможности. Очень интересные горизонты открываются с такими скриптовыми движками в клиенте, снимается множество проблем и добавляется куча новых возможностей (то же самое и отчетных систем касается - тот же FastReport со своим FastScript после доработки напильником очень даже приятно выглядит).
...
Рейтинг: 0 / 0
10.10.2005, 10:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314464
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUSНе очень понятен этот абзац. Если Вы намекаете, что тут собрались исключительно теоретики и проектировщики БД, то смею Вас уверить, предложение Ваше "поднабраться опыта" не выглядит заманчивым

Абсолютно не хотел преуменьшать ваш опыт, просто хотел сказать следующее: я много раз наблюдал, что люди, которые долго специализируются на какой-то одной достаточно универсальной технологии, изучают ее настолько, что могут на ней реализовать почти любую задачу. И в принципе понятно, что другие решения, в которых они разбираются не настолько хорошо, начинают вызывать аллергию. Это же я могу сказать и о себе, когда в середине 90-х, являясь приверженцем TP, спорил с адептами C++ о том, какой язык лучше. Некоторая зашоренность мышления возникает, связанная с тем, что именно сейчас данный конкретный человек именно эту задачу может решить быстрее и эффективнее именно своим отработанным способом, поэтому другие его не особенно и беспокоят.

ASCRUSТак может быть просто стоит задуматься о смене сервера, может быть клиентской части и повышении квалификации, чем переходить на ООП, который по любому для РСУБД, что кривой костыль и мешать парадигмы, где все равно от SQL так или иначе никуда не денешься и обвязка данных обьектами все равно не позволит полностью увести приложение на обьектный уровень, а значит какой в этом толк, если все равно те же отчетники будут требовать SQL, расчеты над множествами данных быстрее работать на ХП и прочее.


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

Насчет универсальных саморазворачивающихся клиентов тоже забывать не надо, да, в случае автоматической генерации форм теряется определенная гибкость, но никто не мешает вам эту форму создать вручную, подход с автоматической генерацией покрывает 80-90% потребностей, оставшиеся 10-20 пишите вручную - кто же вам мешает.

Насчет смены СУБД - да, это актуальный вопрос, но к сожалению он не такой простой и в достаточно большой степени политический, что ли... Да и смена СУБД может упростить собственно написание бизнес-логики в БД, но принципиальных проблем этого подхода не решит.

Вот вы все говорите о том, что кода в ХП у вас мало. Это с какой-то точки зрения говорит и об объеме решаемых вами задач. Вы же не будете отрицать, что существуют задачи, для которых количество кода будет достаточно большим, а поддерживать такой код в общем случае все-таки существенно сложнее, чем такой же по объему ООП-шный клиентский или промежуточного слоя. Я допускаю, что сложность поддержки сильно зависит от конкретной СУБД, но скажем для MSSQL это именно так.
...
Рейтинг: 0 / 0
10.10.2005, 11:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314656
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VladiChВообще разговор перешел в интересную плоскость – не о том, лучше ли многозвенка двухзвенки, а о том, нужна ли объектная прослойка между СУБД и клиентом. По результатам этого обсуждения у меня сложилось впечатление, что адепты двухзвенок и отказа от объектной прослойки просто занимаются разработкой исключительно серверной части, причем с бОльшим упором на базу данных (вернее база данных и является единственной серверной частью), проблемы разработки клиента к этой серверной части от них немного в стороне находятся. Советую поднабраться опыта разработки клиентов и промежуточного слоя на любом ОО-языке, например веб-приложений или веб-сервисов – промежуточный слой в чистом виде. Тогда вопросов уровня “что лучше, ХП или классы”, поубавится.На текущий момент занимаюсь поддержкой многозвенки , посему адептом двузвенки быть не могу (по определению).
Причем многозвенка (4-х) является как раз веб-приложением.

Сделано так, что все звенья, кроме СУБД, построены как слои для преобразования запросов и ответов для следующего звена.
Т.е. имеют простую логику и легко поддерживаются одним программистом. Остальной отдел занимается поддержнокой и развитием только серверной части.
Причина проведения всей основной работы на СУБД проста - при переносе обработки на СП системы становится тормозом (чугунным).

А так все красиво, удобно и быстро.
...
Рейтинг: 0 / 0
10.10.2005, 12:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314770
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Простой рабочий
Почему СП должен тормозить? Почему никто не говорит, что СУБД тормозит?так у вас один сервер приложений или 10-ть (для распределения нагрузки)?

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

А если 10-ть то возникают проблемы параллельного использования и модификации данных (к примеру). И их тоже надо будет разруливать.

VladiChЭхх, ладно, чисто теоретически, на форуме, этот вопрос не разразрешить, тем более людям, у которых имеется много наработок в своей области и мышление уже в какой-то мере зациклено на этом (это я про всех участников обсуждения говорю, в том числе и про себя). Тут надо не на пальцах, а на конкретных примерах обсуждать, что лучше для конкретной задачи. В общем виде такой спор бессмысленен. Я абсолютно согласен, что 2-х звенный для определенного класса задач является самым оптимальным, но то, что это панацея для любой подобной задачи - это уж увольте... И ООП для бизнес-логики тоже вполне применимая и удобная концепция, в обратном вы меня тоже не убедите, т.к. я данный подход давно применяю и вполне успешно.
ИМХО очень зависит от задачи. Поэтому поддерживаю обсуждение на конкретных задачах, но как это сделать?

----

SAnalis.ru - Just for fun. Но мы растем.
...
Рейтинг: 0 / 0
10.10.2005, 12:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314945
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Господа разно звенко-писатели:

У меня предложение:
Может каждый выскажется, в каких ситуациях стоит использовать звено на Сервере Приложений, в каких - нет.

От себя: СП стоит применять, если:
1. Система работает через веб.
2. Очень сложная система (мета-система), которая включает в себя другие системы (возможно также много-уровневые).
2.а Система имеет одновременно веб- и клиентский-интерфейсы. Причем тот и друго выполняют одинаковые функции, тогда все общее выносится на промежуточный уровень.

В остальных - двух-уровневая архитектура.

----

SAnalis.ru - Just for fun. Но мы растем.
...
Рейтинг: 0 / 0
10.10.2005, 13:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33314991
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Ну к примеру задача такая:
Универсальный бизнес-фреймворк, на котором можно создавать различные приложения вплоть до ERP.
Есть три режима - пользовательский, разработчика и администратора. В режиме разработчика можно создавать в системе новые сущности, связи и логику. В режиме администратора можно раздавать права на систему, управлять ее физическими/логическими параметрами и ограниченно редактировать список атрибутов сущностей (без изменения при этом структуры базы данных). Должны быть возможности автоматического построения UI на основе метаданных.
Клиентская часть реализуется на .NET, база данных - MSSQL.
Должна поддерживаться удаленная работа с системой, а также возможность независимой работы на разных базах с последующей репликацией.
Критерии разработки - максимальная расширяемость и масштабируемость системы. Описал задачу с минимальными подробностями, чтобы заранее не ограничивать возможные решения.

Мне просто интересно, как можно спроектировать подобную систему в 2-хзвенном виде? Есть ли примеры реализации подобных систем?
...
Рейтинг: 0 / 0
10.10.2005, 13:53
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315013
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VladiChКлиентская часть реализуется на .NET, база данных - MSSQL.Если не секрет, а почему выбрана платформа .NET и MSSQL от Microsoft.

Интересно, проводилось ли сравнение с J2EE и по каким критериям?

С Уважением, VoDA

----

SAnalis.ru - Just for fun. Но мы растем.
...
Рейтинг: 0 / 0
10.10.2005, 13:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315038
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
VoDAЕсли не секрет, а почему выбрана платформа .NET и MSSQL от Microsoft.

По историческим причинам :). Это был не мой выбор, так что ничего сказать не могу. Но я выбрал бы ту же технологию, потому что собственно на ней специализируюсь.
...
Рейтинг: 0 / 0
10.10.2005, 14:06
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315047
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Но при рассмотрении данной задачи можно и это требование (.NET / MSSQL) отбросить. Разве это что-то поменяет?
...
Рейтинг: 0 / 0
10.10.2005, 14:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315062
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
VladiChНу к примеру задача такая:
Универсальный бизнес-фреймворк, на котором можно создавать различные приложения вплоть до ERP. Типичный пример отсутствия понимания того, что же в итоге должно получиться. Такие "задачи" интересно решать программистам для оттачивания своего мастерства, но с т.з. руководителя такая, с позволения сказать "постановка задачи" есть первейший признак провальности проекта. Вещь в себе, искусство ради искусства. Вместо того, чтобы долго, кропотливо и тщательно выяснять с заказчиком что ему нужно (чаще всего он сам точно не знает) программисты бросаются писать "универсальный фреймворк", который в итоге не может толком решить ни одну реальную задачу.
Вот это все VladiChВ режиме разработчика можно создавать в системе новые сущности, связи и логику. В режиме администратора можно раздавать права на систему, управлять ее физическими/логическими параметрами и ограниченно редактировать список атрибутов сущностей (без изменения при этом структуры базы данных). Должны быть возможности автоматического построения UI на основе метаданных. абсолютно не нужно если вы сразу хорошо представляете ЧТО ИМЕННО должна делать система.
...
Рейтинг: 0 / 0
10.10.2005, 14:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315087
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
А с чего вы взяли, что задача ставилась именно так? По существу вопроса есть что сказать?
...
Рейтинг: 0 / 0
10.10.2005, 14:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315130
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Один1 VladiChНу к примеру задача такая:
Универсальный бизнес-фреймворк, на котором можно создавать различные приложения вплоть до ERP. Типичный пример отсутствия понимания того, что же в итоге должно получиться. Такие "задачи" интересно решать программистам для оттачивания своего мастерства, но с т.з. руководителя такая, с позволения сказать "постановка задачи" есть первейший признак провальности проекта. Вещь в себе, искусство ради искусства. Вместо того, чтобы долго, кропотливо и тщательно выяснять с заказчиком что ему нужно (чаще всего он сам точно не знает) программисты бросаются писать "универсальный фреймворк", который в итоге не может толком решить ни одну реальную задачу.
Вот это все
Присоединяюсь к мнению Одного1. Если вы не располагаете ресурсами Микросцофта то залезание в такой проект закочится вечнонедописанной системой, которую никто не понимает.
Можно посмотреть на это с другой стороны- почему Микрософт, Оракыл и иже с ними до сих пор не написали "универсальный бизнес-фреймворк"? Наверное фантазии не хватило :) Тогда вы зря пиарите здесь свою идею- украдут :)
...
Рейтинг: 0 / 0
10.10.2005, 14:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315178
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Да ема е...
Я не хочу здесь обсуждать возможность реализации подобного проекта.
Разумеется в реальном проекте не все так радужно и он не настолько универсальный, как я написал, я просто не стал в это углубляться чтобы не ограничивать фантазию. Предположим что есть такой проект.
А Microsoft кстати упорно пишет свой бизнес-фреймворк, уже скоро он выйдет.
вот кстати небольшое описание : http://blogs.msdn.com/kevin_ransom/archive/2004/02/27/81391.aspx , на него в скором времени переведут все продукты Microsoft Busines Solutions как то Axapta, Navision, MS CRM и т.п.
Более того, подобных фреймворков существует навалом, возьмем тот же 1С, чем не бизнес-фреймворк?
Тот, который мы разрабатываем немного специфический, не для всех задач от подходит и разумеется по возможностям он не конкурент MBF. Просто я немного так скажем глобализировал задачу, чтобы показать некоторым адептам 2-х звенного подхода, что есть действительно большие задачи, в которых не обойтись ни без сервера приложений ни без объектной прослойки.
...
Рейтинг: 0 / 0
10.10.2005, 14:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315362
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChДа ема е...
Более того, подобных фреймворков существует навалом, возьмем тот же 1С, чем не бизнес-фреймворк?
Тот, который мы разрабатываем немного специфический, не для всех задач от подходит и разумеется по возможностям он не конкурент MBF. Просто я немного так скажем глобализировал задачу, чтобы показать некоторым адептам 2-х звенного подхода, что есть действительно большие задачи, в которых не обойтись ни без сервера приложений ни без объектной прослойки. Первоочердная задача серверов-приложений\очень толстых клиентов одинэс-ки и иже с ней, реализовать Ядро, которое можно использовать, но которое нельзя менять и нельзя посмотреть. Иначе за что платить им деньги?
Таким образом прозрачность, отлаживаемость и простота модификации никоим образом не входит в число задач ПродавцовБольшихФрэймворков. Они лучше предоставят вам скриптовый язык с ключевыми словами на русском и ОченьКрасивыйРедактор схем бизнес-процессов с экспортом в фотошоп.

Представляеете одинэску сделанную на хранимках? Я думаю еще до выхода релиза исходные тексты были бы в сети. Эх размечтался... :)
...
Рейтинг: 0 / 0
10.10.2005, 15:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315425
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Я думаю что 1С-ка реализована так не из-за опасения того, что код куда-то уйдет. Хранимки в конце-концов и шифровать можно. Здесь проблема в другом. И 1С - это все-таки не образец хорошей архитектуры к сожалению, она до сих пор несет отпечаток файл-серверного прошлого в клиент-серверном варианте. Отлаживаемость и простота модификации ядра конечно никак не входит в их приоритеты, а вот простота написания/отладки/расширения функционала на основе ядра безусловно входит.
...
Рейтинг: 0 / 0
10.10.2005, 15:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315431
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Я думаю, что разработчики прикладных решений на основе той же 1С просто застрелились/утопились/повесились бы, если бы им пришлось использовать ядро, написанное на хранимках, да еще и расширять его. Подумайте сами, почему.
...
Рейтинг: 0 / 0
10.10.2005, 15:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315515
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChЯ думаю что 1С-ка реализована так не из-за опасения того, что код куда-то уйдет. Хранимки в конце-концов и шифровать можно.
Шифрование ХП в МС СКЛ вроде бы достаточно легко вскрывается. Подобные темы поднимались в соответствующем форуме.

VladiCh
Отлаживаемость и простота модификации ядра конечно никак не входит в их приоритеты,
а вот простота написания/отладки/расширения функционала на основе ядра безусловно входит.
Соглашусь с вами когда БольшиеПродавцы будут выкладывать свои т.н. Ядра в исходниках и делать деньги скажем на консалтинге. Имхо до этого момента любые их заявления о мотивации выбора той или иной архитектуры родились скорее в отделе маркетинга, а не в отделе разработки.

Впрочем продавцы коробок играют несколько в другую игру, чем типичный АйТи-отдел. Для них например переносимость системы на другую БД не абстрактная возможность, а жизненная необходимость.
Так что не все что хорошо для БольшогоПродавца, хорошо для АйТи-отдела компании, решившей сделать свою систему.
...
Рейтинг: 0 / 0
10.10.2005, 16:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315537
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChЯ думаю, что разработчики прикладных решений на основе той же 1С просто застрелились/утопились/повесились бы, если бы им пришлось использовать ядро, написанное на хранимках, да еще и расширять его. Подумайте сами, почему.
На клиенте можно было оставить старый синтаксис вызовов.

А лезть ли в ядро или в документацию, написанную косноязычным писателем, этот выбор я хотел бы делать сам.
...
Рейтинг: 0 / 0
10.10.2005, 16:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315844
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Эхххх, времени нет, дмой пошел, завтра досмотрю и отвечу еще.

Одно только:
VoDA От себя: СП стоит применять, если:
1. Система работает через веб.
2.а Система имеет одновременно веб- и клиентский-интерфейсы. Причем тот и друго выполняют одинаковые функции, тогда все общее выносится на промежуточный уровень.
Батенька, дык как раз эти пункты как никто другой вас толкают на использование СУБД в качестве движка бизнес логики!!!!!!!!!!!!!
Когда БЛ на сервере СУБД, вам по хрену, откуда и как идет клиент. Хоть через веб, хоть напрямую, хоть как, абсолютно по хрену. Клиент только отображает данные, а данным абсолютно фиолетово, как он их отображает, а бизнес-логике еще более фиолетовее, кто и как отображает данные и работает с системой - дернули ХП, получили результат. Неважно, с веба дернули и через HTML показали, обычный клиент зашел и хрен с горы.

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

Ё.....

-- Tygra's --
...
Рейтинг: 0 / 0
10.10.2005, 18:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315889
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
а40 авторПочему СП должен тормозить? Почему никто не говорит, что СУБД тормозит?Ну как бы разные порядки величины торможения. На фоне СП тормоза СУБД малозаметны.Какова природа возникновения тормозов в СП и чем она отличается от СУБД-шной?

ASCRUSбольшая часть - это вообще собственные системные обьекты, отработанные не один год, работающие во всех наших проектах и организованные по модульной системе, проекты пишутся командой, соответствующе изменения служебных обьектов БД или иерархий классов в клиентской части идут через систему контроля версий и спокойно собираются для остальных проектов... На ASA или Oracle это нормально можно организовать То есть всё равно не голая 2-уровневка - присутствуют и системные объекты, и классы. Да плюс СУБД, с которыми мы не имели дело. Переучивать весь отдел на них я не собираюсь, т.к. слишком высокий риск.

ASCRUSгде все равно от SQL так или иначе никуда не денешься и обвязка данных обьектами все равно не позволит полностью увести приложение на обьектный уровень, а значит какой в этом толк, если все равно те же отчетники будут требовать SQL, расчеты над множествами данных быстрее работать на ХП и прочее Я не знаю, что ответить... Я бы сказал, Вы не прочувствовали кайф от ООП в БЛ :)

VoDAтак у вас один сервер приложений или 10-ть (для распределения нагрузки)? Пока ни одного. В планах 1. Либо если есть мощные рабочие станции, а сервер захлёбывается - снимать нагрузку с сервера на клиентов в виде того же среднего уровня. Как таковых проблем с загруженностью сервера нет (2-3 тяжёлых отчета), есть проблема с поддержкой - вновь прибывшим на работу программерам сложно разобраться в том, что же эта система делает:), поэтому есть идея реализовать бизнес-логику отдельно, используюя ООП.

VladiCh
Хочу задать несколько вопросов, можешь написать мне? (мой адрес не скрыт)
...
Рейтинг: 0 / 0
10.10.2005, 18:49
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33315954
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
VladiChНу к примеру задача такая:
Универсальный бизнес-фреймворк, на котором можно создавать различные приложения вплоть до ERP.
Есть три режима - пользовательский, разработчика и администратора. В режиме разработчика можно создавать в системе новые сущности, связи и логику. В режиме администратора можно раздавать права на систему, управлять ее физическими/логическими параметрами и ограниченно редактировать список атрибутов сущностей (без изменения при этом структуры базы данных). Должны быть возможности автоматического построения UI на основе метаданных.
Клиентская часть реализуется на .NET, база данных - MSSQL.
Должна поддерживаться удаленная работа с системой, а также возможность независимой работы на разных базах с последующей репликацией.
Критерии разработки - максимальная расширяемость и масштабируемость системы. Описал задачу с минимальными подробностями, чтобы заранее не ограничивать возможные решения.

Мне просто интересно, как можно спроектировать подобную систему в 2-хзвенном виде? Есть ли примеры реализации подобных систем?Да, примерно то, что вы описали, реализовано в двухзвенке - сервер Oracle, клиентская часть на PowerBuilder. Вот здесь (и далее в топике) я отвечал на вопросы по этой разработке.

Не реализована (пока нет в этом потребности) работа через WEB, но кое-какой задел, для простого переноса на mod_plsql имеется.
Независимая работа с разными базами с последующей репликацией - если речь идет о метаинформации, то изменения накатываются специальным скриптом, который генерится из среды разработки.

На этом движке реализовано несколько пректов.
...
Рейтинг: 0 / 0
10.10.2005, 19:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316059
777777777
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
777777777
Гость
VoDAГоспода разно звенко-писатели:

У меня предложение:
Может каждый выскажется, в каких ситуациях стоит использовать звено на Сервере Приложений, в каких - нет.

От себя: СП стоит применять, если:
1. Система работает через веб.
2. Очень сложная система (мета-система), которая включает в себя другие системы (возможно также много-уровневые).
2.а Система имеет одновременно веб- и клиентский-интерфейсы. Причем тот и друго выполняют одинаковые функции, тогда все общее выносится на промежуточный уровень.

В остальных - двух-уровневая архитектура.



Еще можно добавить, если удаленный клиент работает по "плохим" каналам связи.
...
Рейтинг: 0 / 0
10.10.2005, 21:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316113
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЯ не знаю, что ответить... Я бы сказал, Вы не прочувствовали кайф от ООП в БЛ :)
Эх, за столько лет десятки проектов, куча крупных ... так я и погибну, не прочувствовав кайф от ООП в обработке множеств данных Меня греет единственная надежда, что все таки MS и Sun не зря внимания в последнее пристальное време обратили на функциональные языки и структуры, можно сказать уже малость положив на ООП. Кстати я не понимаю - если так все нравится, почему бы не обратить внимание на тот же CACHE или FastObjects - действительно системы реализуют именно то, о чем говорят поклонники ООП и многозвенок, причем неплохо реализуют, чем пытаться обязательно прикрутить ООП к ни в чем не виноватым РСУБД.
...
Рейтинг: 0 / 0
10.10.2005, 23:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316315
Кашист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кашист
Гость
авторбы не обратить внимание на тот же CACHE или FastObjects - действительно системы реализуют именно то, о чем говорят поклонники ООП и многозвенок, причем неплохо реализуют
Не скажу за FastObjects, но Cache' - это пародия на ООП. Да классы, есть, есть в них методы, но структуры хранения не наследуются - по умолчанию все будет сваливаться в один глобал (таблицу). Есть возможность переопределить стратегию хранения, но тогда, изменения в базовом классе вам придется прописывать вверх на всю иерархию классов.
Добавить к этому абсолютно убогую среду разработки, отсутствие нормального дебагера (объектный код транслируется в рутины и только их и можно дебажить - что уже совсем не тот код, который писал разработчик). Ну и добавить к этому отссутсвие квалифицированных разработчиков - их единицы и их нужно растить...
В общем, быстрее и разумнее написать СП на .Net и какой-нибудь известной РСУБД, чем пытаться выжать что-то из Cache. Что подтвержается и выборкой применения Cache - 90% самописные COS системы - это та область, где Сache действительно даст фору практически любой СУБД - но это не ООП, это наборот Assembler :)
...
Рейтинг: 0 / 0
11.10.2005, 08:39
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316376
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну вот, появилось время, можно и подумать :))

Простой рабочийЯ не знаю, что ответить... Я бы сказал, Вы не прочувствовали кайф от ООП в БЛ :)
Зачем нам такой кайф - паленый однако :))
Вот вы не прочувствавали кайф от БЛ на сервере СУБД и всеми вкусностями, с этим связвнными - вай-вай, некарашо, вы пропустили очень много, ОЧЕНЬ МНОГО!

Простой рабочийПока ни одного. В планах 1. Либо если есть мощные рабочие станции, а сервер захлёбывается - снимать нагрузку с сервера на клиентов в виде того же среднего уровня . Как таковых проблем с загруженностью сервера нет (2-3 тяжёлых отчета), есть проблема с поддержкой - вновь прибывшим на работу программерам сложно разобраться в том, что же эта система делает:), поэтому есть идея реализовать бизнес-логику отдельно, используюя ООП .
Я бы выразил данную ситуацию одним емким словом, но нельзя тутЮ потому несколькими словами постараюсь. :)
По первому выделенному фрагменту - крутая система, ничего не скажешь, чтобы клиент работал, ему на компутер еще и среднее звено поставить. и так каждому Какова архитектура, какова мысль!!! Просто супер-система!!! Одолжите траву (далее слова восхищения, уже неприменимые к данному форуму) :)
По второму фрагменту - давайте, вперед, мало того, что сейчас уже сложно, сделайте, чтобы вообще нельзя было разобраться! Никак! Тогда работа вам обеспечена на всю жизнь! Далее слов нет.

============================================

Теперь более серьезно.
Господа, реализующие разные обертки вокруг таблиц и ХП. Вот расскажите пожалуста, вы так делаете потому что:
1. У вас много времени, делать нечего, поэтому вы проводите различные изыскания по различным вариантам усложнения систем.
2. Много времени не только на разработку, но и на поддержку системы, к тому же вы получаете кайф о многочисленных пересборок/выкладываний клиентских ехе из-за правки пары запятых или нулей и т.д.
3. Вы не умеете работать с СУБД и писать на бизнес-логику на SQL
4. Вы не умеете к тому же работать с хранимыми процедурами из клиентского приложения.

Ничего другого не приходит на ум - смысл заниматься таким мазохизмом я не вижу вообще никак.
Может быть вы действительно не знаете, как можно работать с СУБД из клиента и не видели действительно серьезных и человеческих систем - расскажем и покажем, книги пока нет, но уж как-нибудь.

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

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 09:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316434
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Тигра, я давно уже махнул рукой и не только в этом форуме, но везде. Людей, хорошо понимающих архитектуру приложений в России почти не осталось. Все кого я знаю сейчас за границей. Остальные просто делают молча свою работу.

От них я понял золотое правило. Чем проще, тем надежнее. Те кто говорят, у нас это не пройдет потому что система сложная, просто не знают как сделать это просто.

Хороший пример бизнес логики на сервере это система NEXUS

В этой системе абсолютно вся бизнес логика на сервере. То есть можно работать с этой системой из Query Analyzer, и при этом не нарушить логику.

Мало того что вс БЛ на сервере, так она еще и объектно-ориентированная. Кто-то говорил, что с помощью процедур нельзя сделать инкапусляцию, посмотрите NEXUS, там она есть. Работая из QA вы не сможете напрямую вызывать процедуры, вы работаете с одной интерфейсной таблицей, в которую вводите данные и из которой получаете назад данные от сервера. Все методы вызываются с помощью одной процедуры и только она определяет, что можно сделать с данным объектом.

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

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 09:44
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316442
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Накипело. Надоело слушать рассуждения о колбасных обрезках.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 09:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316467
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Да, это точно.


-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 09:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316503
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
А мне кажется, что можно найти более актуальные темы для горячечных споров. Сегодня ни для кого уже не секрет, что следующие N-е количество лет компьютерная техника будет развиваться уже несколько по-другому, т.е. рост производительности будет за счет множества однотипных процессоров на плате(в кристалле). Для самого железа не бог весть какие революционные изменения, но вот для софта, это очень даже революционные! Софт будет меняться очень радикально, и стать насквозь параллельным. Так что нынешняя тема об условном делении/группировки кода по уровням становится не актуальным. Мне кажется, разумнее поразмышлять о параллельных алгоритмах, тех, которые вы считаете наиболее важными для себя. Мне кажется, что многие нынешние подходы в программировании, к которым мы привыкли, "выживут" не все. Параллельная природа железа будет тому виной. Самые большие изменения будут у компиляторов, тут по-видимому возможно много новых имен. Кокое место будет занимать операционная система,-тоже вопрос. Может оказаться, что много больше чем сегодня будет делаться машинным кодом, сгенерированным параллельным компилятором, а у ОСи лишь некоторые базовые функции, ну, и т.д. и т.п. Ясно одно, что программирование усложняется очень сильно.
...
Рейтинг: 0 / 0
11.10.2005, 10:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316568
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
Простой рабочийКакова природа возникновения тормозов в СП и чем она отличается от СУБД-шной? ООП не предназначен для обработки множеств. Вы не сделаете JOIN быстрее, чем сервер БД. ASCRUS неоднократно и подробно об этом писал.

Простой рабочий
VoDAтак у вас один сервер приложений или 10-ть (для распределения нагрузки)? Пока ни одного this is it
Постоянно наблюдаю, что самые горячие сторонники "серверов приложений" - те, кто их никогда не писал и не внедрял.

Так что пишите, создавайте свои многоуровневые системы. Один раз это сделать нужно. "n tier application" - это хороший пункт в резюме, очень люблю когда он есть у кандидатов
...
Рейтинг: 0 / 0
11.10.2005, 10:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316698
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
И тишина... :-) все задумались, умолкли спорщики :-)
Эк я всех зацепил :-)
...
Рейтинг: 0 / 0
11.10.2005, 11:15
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33316703
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
Один1ООП не предназначен для обработки множеств. Вы не сделаете JOIN быстрее, чем сервер БД. ASCRUS неоднократно и подробно об этом писал.
Полностью присоединяюсь. Именно это и хотел сказать в предыдущих постах.

tygraБатенька, дык как раз эти пункты как никто другой вас толкают на использование СУБД в качестве движка бизнес логики!!!!!!!!!!!!!
-- Tygra's --Я имел в виду, не место расположения бизнес-логики, а вообще применимость сервера приложений.

Для примера опишите, как вы будете реализовать веб-сервисы и доступ по SOAP-протоколу на MS-SQL сервере. Причем непременное условие: без какого либо промежуточного звена. (бройзер ломится на SQL, клиент - тоже). Наверное можно привинтить собственный движок для генерации html, но это не то.

То, что большую часть (из стратегии простоты системы) стоит разместить на СУБД, в этом я согласен.

PS: может я не знаю и MS SQL уже начал как Sybase ASA выдавать html-страницы.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
11.10.2005, 11:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317297
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
VoDA,
насчет того, что SQL сервер построит выборку быстрее нет сомнений, это его хлеб. Но что дальше будете делать с выборкой - пересылать клиентам? И сервер будет заниматься её обработкой?
Здесь я с Вами принципиально расхожусь. Я за сервера приложений и распределенные вычисления.
Достаточно долго разрабатывал системы управления тех. процессами. Там эти споры заглохли давно - контроллеры имеют право на существование. Но разницу между этими областями понимаю.

Суважением, Владимир.
...
Рейтинг: 0 / 0
11.10.2005, 13:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317302
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторЯ имел в виду, не место расположения бизнес-логики, а вообще применимость сервера приложений.

Для примера опишите, как вы будете реализовать веб-сервисы и доступ по SOAP-протоколу на MS-SQL сервере. Причем непременное условие: без какого либо промежуточного звена . (бройзер ломится на SQL, клиент - тоже). Наверное можно привинтить собственный движок для генерации html, но это не то.
Вы сами же выделили собственно ответ.
Промежуточное звено не есть сервер приложений.
Если считать просто промежуточные звенья, то их насчитается в обычной к-с несколько - от драйверов к бд до самой операционной системы.

Но нам ведь такие звенья не нужны, неправда ли? Они ничего фактически для приложения не значат, кроме предоставления доступа к данным.

Вот и вебсервис - это всего лишь провайдер доступа. Тупо передает данные туда и обратно. Он никак не является сервером приложений - просто большой драйвер доступа к СУБД через интернет например.

А вот когда этот драйвер начинает брать на себя БЛ - вот тогда он становится СП. И вот такие нам не нужны в общем случае.

=====

Да, что-то все затихли.

И все же хотелось бы услышать ответы.
И на эти вопросы от DrKonito так же - очень хотелось бы услашать

-- Tygra\'s --
...
Рейтинг: 0 / 0
11.10.2005, 13:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317319
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
ВМоисеевнасчет того, что SQL сервер построит выборку быстрее нет сомнений, это его хлеб. Но что дальше будете делать с выборкой - пересылать клиентам? И сервер будет заниматься её обработкой?
А что еще можно делать с выборкой, кроме как передать клиентам или обработать? Вы знаете другие применения?

авторЗдесь я с Вами принципиально расхожусь. Я за сервера приложений и распределенные вычисления.
Доводы то где?
Доводы за катастрофическое усложнение системы путем добавления звеньев, оберток и т.д.? Никто не хочет доводы показать - "за СП" и все. Нет чтоли чего сказать?

авторДостаточно долго разрабатывал системы управления тех. процессами. Там эти споры заглохли давно - контроллеры имеют право на существование. Но разницу между этими областями понимаю.
И что - контроллеры?
Сколько людей здесь с ними работает? Возможно контроллеры и являются потребителями СП - но уж бухгалтерия то тут совсем не при чем. :)

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 13:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317329
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Когда же нам покажут пример обертки и довод к ее использованию???
Я уже жду, устал аж. :)

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 13:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317418
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Господа Один1, tygra, Old Nick и ASCRUS, вы все говорите правильно, но возражаете на те заявления, которых здесь не было. Разговор вообще о другом идет. Никто не спорит, что работа с множествами должна вестись на SQL-сервере. Где вы видели обратное утверждение - ткните пальцем пожалуйста... Речь идет о том, что эту бизнес-логику удобнее всего структурировать по ООП-принципам, что сделать в базе данных если и можно, о чем здесь говорил Old Nick, то честно говоря через одно место.
СУБД для этого не предназначена, так же как и ООП не предназначено для работы с множествами. Я не спорю, что сделать эмуляцию ООП на процедурном языке, предназначенном для работы с множествами можно, только зачем? Это будет криво и неудобно.

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

Я соглашусь - большая часть бизнес-логики реализуется именно в БД (не вся). Но клиент работает с этой бизнес-логикой через объектную прослойку, а не через запросы и рекордсеты. Сервер приложений в данном случае выполняет вспомогательные функции, но это все же не провайдер доступа к СУБД через интернет, не надо утрировать. Объектная прослойка - это ведь не просто обертка, через которую выполняются CRUD-операции над таблицей. Ее функции могут быть гораздо шире.

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

Доводы за СП - вынести часть работы, общую для всех клиентов, например кэширование, зависящее от логики приложения (не единственный пример). Разгрузить сервер БД тоже можно в некоторых случаях, хотя конечно в большинстве типовых задач корпоративных ИС это довольно сложно сделать - проще проапгрейдить железо на котором СУБД крутится.
...
Рейтинг: 0 / 0
11.10.2005, 13:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317488
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
ВМоисеевVoDA,
насчет того, что SQL сервер построит выборку быстрее нет сомнений, это его хлеб. Но что дальше будете делать с выборкой - пересылать клиентам? И сервер будет заниматься её обработкой?
Давайте определимся что называть обработкой.
ВМоисеевЗдесь я с Вами принципиально расхожусь. Я за сервера приложений и распределенные вычисления.
Достаточно долго разрабатывал системы управления тех. процессами. Там эти споры заглохли давно - контроллеры имеют право на существование. Но разницу между этими областями понимаю.

Суважением, Владимир.
tygraПромежуточное звено не есть сервер приложений.

Вот и вебсервис - это всего лишь провайдер доступа. Тупо передает данные туда и обратно. Он никак не является сервером приложений - просто большой драйвер доступа к СУБД через интернет например.

А вот когда этот драйвер начинает брать на себя БЛ - вот тогда он становится СП. И вот такие нам не нужны в общем случае.И что сервером приложений.

А то складывается ощущение, что каждый говорит о чем-то своем.

PS обработкой я называю любые изменения в данных, т.е. получил xml на вход изменил/преобразовал данные и отправил дальше и/или инициировал другое(ие) действия (драйвера на изменяют данных, а преобразуют форму их представления).
СП - тогда это та программа, которая эти изменения производит.

Извиняюсь, если выразился не достаточно четко.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
11.10.2005, 14:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317531
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
VladiChГоспода Один1, tygra, Old Nick и ASCRUS, вы все говорите правильно, но возражаете на те заявления, которых здесь не было. Разговор вообще о другом идет. Никто не спорит, что работа с множествами должна вестись на SQL-сервере. Где вы видели обратное утверждение - ткните пальцем пожалуйста... Речь идет о том, что эту бизнес-логику удобнее всего структурировать по ООП-принципам, что сделать в базе данных если и можно, о чем здесь говорил Old Nick, то честно говоря через одно место.
Так мы и просим: покажите, с чего бы это бизнес-логику удобнее структурировать по ООП-принципам ??? Кто вам сказал, что это так? Что вы именуете бизнес-логикой? Пробовали вы реализовать ее хоть раз в СУБД, только правильно, а не с позиций ООП?
Я же писал: непонятно, зачем вы себе усложняете жизнь?! Приведите пример, объяснения. Мы приведем пример того же, но со стороны СУБД. Иначе совершенно непонятно, на кой вам ООП для данных и БЛ?

авторСУБД для этого не предназначена, так же как и ООП не предназначено для работы с множествами. Я не спорю, что сделать эмуляцию ООП на процедурном языке, предназначенном для работы с множествами можно, только зачем? Это будет криво и неудобно.
Вот мне не нужны данные, структурированные по ООП принципам - они сделают только хуже, как не нужно и все другое, ООП-овидное в вашем смысле, на стороне СУБД. А вам зачем?

авторЯ соглашусь - большая часть бизнес-логики реализуется именно в БД (не вся). Но клиент работает с этой бизнес-логикой через объектную прослойку, а не через запросы и рекордсеты. Сервер приложений в данном случае выполняет вспомогательные функции, но это все же не провайдер доступа к СУБД через интернет, не надо утрировать. Объектная прослойка - это ведь не просто обертка, через которую выполняются CRUD-операции над таблицей. Ее функции могут быть гораздо шире.
Зачем оно вам вне СУБД?

авторДоводы за СП - вынести часть работы, общую для всех клиентов, например кэширование, зависящее от логики приложения (не единственный пример).
У вас с этим проблемы, из-за которых приходится выносить? СУБД что, уже не справляется?

-----------

VoDA PS обработкой я называю любые изменения в данных, т.е. получил xml на вход изменил/преобразовал данные и отправил дальше и/или инициировал другое(ие) действия (драйвера на изменяют данных, а преобразуют форму их представления).
СП - тогда это та программа, которая эти изменения производит.
Так вот и определитесь - если есть какая-то обработка, изменяющая данные, то это СП. Если есть обработка, преобразующая данные в другой вид - это драйвер. Вебсервис, который получает что-то, идет в БД, дергает ХП, получает результат, отдает что-то и на этом его работа заканчивается (ну примерно так) - это большой драйвер доступа к БД.

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 14:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317671
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
tygraТак вот и определитесь - если есть какая-то обработка, изменяющая данные, то это СП. Если есть обработка, преобразующая данные в другой вид - это драйвер. Вебсервис, который получает что-то, идет в БД, дергает ХП, получает результат, отдает что-то и на этом его работа заканчивается (ну примерно так) - это большой драйвер доступа к БД.

-- Tygra's --То есть получается (к примеру) веб сервис построенный на J2EE с использованием JBoss и сервлетов под Tomcat - является драйвером , а сам JBoss - перестает быть сервером приложений?

Разговор становится интереснее с каждым постом.
----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
11.10.2005, 15:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317707
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraТак мы и просим: покажите, с чего бы это бизнес-логику удобнее структурировать по ООП-принципам ??? Кто вам сказал, что это так?

Самый простой пример. Ну к примеру, существует сущность "товар". Существуют правила ценообразования для товара. Существует также несколько сущностей, унаследованных от "товара" как на уровне таблиц, так и на уровне классов бизнес-логики. На уровне таблиц наследование осуществляется отношением 1:1. Для этих унаследованных сущностей переопределены правила ценообразования, также добавлено несколько дополнительных атрибутов. На уровне клиенте я могу работать со всеми этими сущностями как с "товаром", менять их атрибуты и т.п. Правила ценообразования задаются формулами, которые могут транслироваться в выражения SQL, можно сказать, что логика ценообразования в результате работает в СУБД, но для того чтобы это было так, промежуточный слой должен довольно много телодвижений сделать.

К примеру, я просто выбираю все "товары", в том числе и унаследованные.
Выражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.

Есть свой язык для выборки объектов + набор универсальных хранимых процедур, в которые передаются "полураспарсенные" конструкции этого языка. Этими несколькими хранимыми процедурами генерится динамический SQL для выборки коллекции объектов.

Обработка результата тоже производтся в промежуточном слое, на выходе получается коллекция объектов класса "Товар".

Для каждой сущности определен набор операций, на операции завязана система security. На базовую сущность Entity завязаны права на выборку, чтение, создание, модификацию, удаление, редактирование прав, которые соответствуют различным операциям над этой сущностью. Операции наследуются точно также как на уровне СУБД, так и на уровне классов. Т.е. все унаследованные сущности будут иметь тот же набор операций, что и Entity + могут задаваться свои.

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

tygraУ вас с этим проблемы, из-за которых приходится выносить? СУБД что, уже не справляется?

Разумеется. У меня логика кэширования зависит от логики приложения, а не от логики СУБД.

tygraВот мне не нужны данные, структурированные по ООП принципам - они сделают только хуже, как не нужно и все другое, ООП-овидное в вашем смысле, на стороне СУБД. А вам зачем?

А у меня структурируются не только данные, но и операции над объектами, как я описал выше.
...
Рейтинг: 0 / 0
11.10.2005, 15:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317716
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Мне кажется, tygra сформулировал суть достаточно четко и верно.
...
Рейтинг: 0 / 0
11.10.2005, 15:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317736
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторВыражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.

Да ну... Ну что нельзя сделать в MS SQL Server? Чур решения дифф. уравнений не предлагать :)
...
Рейтинг: 0 / 0
11.10.2005, 15:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317752
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
авторДа ну... Ну что нельзя сделать в MS SQL Server? Чур решения дифф. уравнений не предлагать :)

Парсер своего языка запросов оччень я бы сказал проблематично построить.
...
Рейтинг: 0 / 0
11.10.2005, 15:35
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317775
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Да, с парсером согласен.
...
Рейтинг: 0 / 0
11.10.2005, 15:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317778
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Что скажет Тигра в ответ на парсер? :)
...
Рейтинг: 0 / 0
11.10.2005, 15:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317786
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
tygraДоводы за катастрофическое усложнение системы путем добавления звеньев, оберток и т.д.? Никто не хочет доводы показать - "за СП" и все. Нет чтоли чего сказать?
Тебе их показывали - ты их не хочешь вопринимать. Сразу видно - со школьной скамьи с турбо паскаля перелез на SQL, не сделав ни одного грамотного проекта с использованием ООП.
Усложнение не катастрофическое. Делается ОДИН раз. Дальше СП работает сам по себе. Очень легко менять бизнес-логику.

tygraПробовали вы реализовать ее хоть раз в СУБД, только правильно, а не с позиций ООП?
В этом-то вся и проблема. Почему ты решил, что логика правильная только на СУБД? Где это написано? Правда-то у всех своя. Работает у тебя логика на СУБД? Отлично, ты прав! Работает у других на СП? Отлично, и они правы!

Если кому не сложно поделиться достижениями в проектировании серверов приложений - всегда рад прочесть.
...
Рейтинг: 0 / 0
11.10.2005, 15:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317831
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
VladiCh авторДа ну... Ну что нельзя сделать в MS SQL Server? Чур решения дифф. уравнений не предлагать :)

Парсер своего языка запросов оччень я бы сказал проблематично построить.
А его и не надо строить в СУБД - уже есть готовый и мощный - это сам SQL - никто не мешает хранить ценообразование товаров в текстовом поле таблицы алгоритмов в виде готового куска батча SQL, хоть с переменными, хоть с времянками, хоть с чертом на куличках и при надобности через динамический SQL его вызывать.
...
Рейтинг: 0 / 0
11.10.2005, 15:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317864
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUSА его и не надо строить в СУБД - уже есть готовый и мощный - это сам SQL
Так он и не строится в СУБД по причине, описанной выше - строится на промежуточном слое, в СУБД передается уже результат его работы. По поводу в принципе использования своего языка...
Очень не хочется здесь всю архитектуру приложения описывать, т.к. кучу времени займет, но поверьте, одним SQL-ем здесь не обойтись... Он используется на клиенте для выборки коллекций объектов с использованием связей между сущностями. Связи также описаны в метаданных. Помимо обычных атрибутов, хранящихся в таблицах, есть т.н. "расширенные" атрибуты, хранящиеся вертикально в отдельной таблице, в принципе по ним также может осуществляться сортировка и поиск. Если это все писать на чистом SQL... Сложновато получается и непонятно, мягко говоря. На клиенте меня не интересуют таблицы и view, меня интересуют сущности в моей системе, в терминах этих сущностей и работают выборки с использованием своего языка.
Да и выборки получаются не очень простые, на 2-3 рекордсета в среднем, их приведение к коллекции объектов осуществляется отдельно, поэтому сам результат выполнения SQL-выражения мне на клиенте тоже неинтересен.
...
Рейтинг: 0 / 0
11.10.2005, 16:06
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317890
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Пример неудачный. Если у вас ценообразованием занимается метод, то привяжите к каждому типу товара метод и вызывайте его через один базовый виртуальный метод товара. Есть проблемы в реализации? Нехрен тогда спорить о плюсах и минусах.

Выбрать на клиента все товары, в том числе и унаследованные? Делается не просто, а очень просто: select * from Things (если все виды товаров наследуются от одного базового, то выборку делаем из базовой таблицы)

А по сути, ценообразование это список стоимостей, входящих в него составляющих. Что такое составляющие? Это сам товар, его составляющие (допустим, приход на склад в виде комплектующих, а расход со склада в виде готового компа), услуги по его продаже, услуги по его сборке, скидки на его продажу, накрутки на него, налоги на него и т.д. и т.п. И подсчет делается простым агрегирующим селектом.

Не усложняйте господа, то что в мире сделано просто.
...
Рейтинг: 0 / 0
11.10.2005, 16:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317919
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Old NickПример неудачный. Если у вас ценообразованием занимается метод, то привяжите к каждому типу товара метод и вызывайте его через один базовый виртуальный метод товара. Есть проблемы в реализации? Нехрен тогда спорить о плюсах и минусах.

Выбрать на клиента все товары, в том числе и унаследованные? Делается не просто, а очень просто: select * from Things (если все виды товаров наследуются от одного базового, то выборку делаем из базовой таблицы)

Садитесь, 2!
Эти два метода неравноценны.
Расскажите мне тогда немного о том, что вы понимаете под полиморфизмом.
В случае такой выборки вы получите коллекцию объектов типа Товар, т.е. унаследованные товары будут без своих дополнительных атрибутов, соответственно по ним некорректно будут рассчитаны цены. Я же в своем случае получу коллекцию разнотипных объектов, типы которых унаследованы от типа "Товар", к которым буду обращаться так, как будто это объекты типа "Товар".

Old NickА по сути, ценообразование это список стоимостей, входящих в него составляющих. Что такое составляющие? Это сам товар, его составляющие (допустим, приход на склад в виде комплектующих, а расход со склада в виде готового компа), услуги по его продаже, услуги по его сборке, скидки на его продажу, накрутки на него, налоги на него и т.д. и т.п. И подсчет делается простым агрегирующим селектом.

Вот именно, а скидки на него начисляются в зависимости от того, какого типа товар. К разным типам товаров применимы разные типы скидок, рассчет может делаться разными способами, скидки могут суммироваться/не суммироваться и т.п. Вы предлагаете все это сделать простым аггрегирующим селектом? Ну-ну.
...
Рейтинг: 0 / 0
11.10.2005, 16:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317920
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторОчень не хочется здесь всю архитектуру приложения описывать, т.к. кучу времени займет, но поверьте, одним SQL-ем здесь не обойтись...
К сожалению не поверю, потому что у меня все замечательно обходится одним SQL, который ко всему прочему для подобных случаев строится на стороне сервера и выполняется на стороне сервера. Клиентское приложение только передает серверу, что ему нужно и получает готовый результат, даже если алгоритмы плавающие и на момент вызова клиентское приложение не знает ничего кроме инициализирующих параметров - это уже проблемы сервера и бизнес-логики, как и что будет выбираться, считаться, собираться, выполняться. Наглядный пример - у меня полностью на языке ХП реализован система фильтров, позволяющая на уровне сущностей описать запросами получение параметров обьектов в различных разрезах, с дополнительными аттрибутами, необходимыми клиентскому приложению для построения формы запроса параметров фильтрации на необходимые обьекты. Клиентское приложение заполняет своими условиями по определенным аттрибутам разрезов времянку (фактически для пользователя это выглядит как работа в списке разрезов и аттрибутов мышкой), далее вызывается ХП, которая по параметрам времянки собирает SQL запрос, со всеми подзапросами по разрезам и условиями, заданными пользователем и выполняет его. Если интересно - код такой ХП занимает ровно 83 строчки, вместе с комментариями.

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

P.S. Скрипты просто замечательно собираются и выполняются сервером и клиентская часть никаких затруднений для отображения универсальной формы запроса параметров фильтрации не имеет, достаточно бросить в приложение компонент и назначить ему указанную схему фильтрации.
...
Рейтинг: 0 / 0
11.10.2005, 16:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317938
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUSК сожалению не поверю, потому что у меня все замечательно обходится одним SQL

То что у ВАС обходится замечательно одним SQL, не обязательно должно во всех случаях обходиться одним SQL, вам не кажется? Особенно, если учесть мягко говоря существенную разницу в архитектуре приложения. Критиковать же архитектуру не имея мало-мальских данных о самом приложении мне кажется несколько опрометчиво.
...
Рейтинг: 0 / 0
11.10.2005, 16:32
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317959
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ASCRUS, я верю, что вы просто виртуоз SQL и можете на нем сделать все что угодно. Я не верю в то, что методы, применяемые вами являются единственно верными в любой ситуации. Я не уверен в этом и для своих методов. А пока я в этом не уверен, я не буду всем советовать срочно начать использовать мои методы и все остальные приложения, реализованные не так подозревать в кривой архитектуре, что и всем остальным советую.
...
Рейтинг: 0 / 0
11.10.2005, 16:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317977
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Ах, простите, я забыл что у вас ценообразование на клиенте происходит :-)

Поясняю насчет полиморфизма. У вас есть метод задача которого для каждого экземпляра из списка товаров вызвать метод ценообразования и полученный результат записать напротив товара. Значит данный метод виртуальный и его единственная задача по идентификатору товара определить его тип, по типу найти реальный метод и вызвать его. Это можно сделать на клиенте, можно и в базе. Где быстрее будет? Или есть проблемы с созданием в реляционной базе виртуальных и перекрывающих метод?

На клиенте это можно сделать двумя способами:
1. Имея список товаров (select * from Things) для каждого элемента вызвать процедуру соответствующую типу товара
2. Выгрести на клиента список всех товаров со всеми возможными атрибутами, используя для этого все возможные построители динаимческого SQL, и затем пробежать по списку посчитав для каждого экземпляра цену и затем таким же макаром сохранить это в базе.

Вы какой способ выбираете?

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 16:44
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317979
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Я не критикую - я не верю Вашим заявлениям о том, что на SQL не реализуемо. Почувствуйте разницу. Вы говорите что нельзя, а я по своему опыту знаю, что можно, Вы приводите примеры, а я вижу что это элементарно вписывается в логику БД. Но я не заявляю, что это 3-х звенки и ООП не могут. Я заявляю, что SQL может. Однако я подчеркиваю, что раз SQL может, то на фига сдался лишний код и лишние звенья ?
...
Рейтинг: 0 / 0
11.10.2005, 16:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33317990
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Я не говорю, что не реализуемо никогда и не прикаких обстоятельствах, я даже не говорил, что это и у меня нереализуемо. Это просто _нецелесообразно_ именно в моей архитектуре. Почуствуйте разницу. В вашей это может замечательно работать.
...
Рейтинг: 0 / 0
11.10.2005, 16:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318022
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Old NickАх, простите, я забыл что у вас ценообразование на клиенте происходит :-)
?? Откуда вы это взяли?

Old NickПоясняю насчет полиморфизма. У вас есть метод задача которого для каждого экземпляра из списка товаров вызвать метод ценообразования и полученный результат записать напротив товара. Значит данный метод виртуальный и его единственная задача по идентификатору товара определить его тип, по типу найти реальный метод и вызвать его.
?? А это откуда?

Ценообразование у меня выполняется в SQL, еще в момент выборки, прочитайте внимательно еще раз . но в то же время на клиенте мне нужны полноценные объекты своих типов, а не кастрированные путем select * from Things.

Old NickИли есть проблемы с созданием в реляционной базе виртуальных и перекрывающих метод?
А это, извините меня, и есть то, что я называл извращением.
...
Рейтинг: 0 / 0
11.10.2005, 16:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318027
Простой рабочий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Простой рабочий
Участник
ASCRUSНиже привожу скриншот пользовательского компонента запроса параметров фильтрации, который автоматически по указанной схеме выводит окно, заносит во времянку параметры выбора (операции и значения на указанные аттрибуты) и далее просто вызывает ХП. В этом примере я наверное тоже обошёлся бы ХП.
...
Рейтинг: 0 / 0
11.10.2005, 16:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318039
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
А зачем Вам на клиенте нужны полноценные объекты? Что Вы с ними делать будете на клиенте?
...
Рейтинг: 0 / 0
11.10.2005, 17:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318073
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh Выражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.

Извините, не удержался. Что для чего "слабо приспособлено"?! язык SQL для обрабтки реляционных данных?! %) Это если структуру хранения данных создать так, что он станет "слабо приспособленным".

VladiCh Есть свой язык для выборки объектов + набор универсальных хранимых процедур, в которые передаются "полураспарсенные" конструкции этого языка. Этими несколькими хранимыми процедурами генерится динамический SQL для выборки коллекции объектов.

Мдя... Если я вижу систему, в которой существует набор "универсальных" хранимых процедур, которые генерят DSQL, то сразу становиться понятным, что разработчик мало времени потратил именно на проектирование нормальной "структуры" хранения данных и алгоритмами ее обработки.

Применение ООП на клиенте, ради бога, но не надо "извращаться" над реляционными СУБД.
...
Рейтинг: 0 / 0
11.10.2005, 17:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318076
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Old NickА зачем Вам на клиенте нужны полноценные объекты? Что Вы с ними делать будете на клиенте?
Вопрос на миллион долларов :). Вы знаете, я, как ни странно, буду вызывать их методы :). Причем у объекта типа SpecificThing1 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething1 с передачей параметра param1, где param1 - это дополнительное свойство SpecificThing1. А у объекта SpecificThing2 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething2 с передачей параметра param2, где param2 - это дополнительное свойство SpecificThing2.
Свойства param1 и param2 выбираются из полей таблиц SpecificThing1 и SpecificThing2, т.е. в таблице Things не присутствуют. Классы SpecificThing1 и SpecificThing2 унаследованы от класса Thing, данные которого хранятся в таблице Things. А select * from Things мне в этом случае вернет нечто непонятное.
...
Рейтинг: 0 / 0
11.10.2005, 17:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318080
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinИзвините, не удержался. Что для чего "слабо приспособлено"?! язык SQL для обрабтки реляционных данных?!

Там что-то говорилось про реляционные данные? Там говорилось про логику построения SQL-выражения из выражения на своем языке запросов. То есть по вашему SQL приспособлен для того, чтобы парсить какие-то текстовые выражения? Но я надеюсь вы этого не имели в виду, а просто невнимательно прочитали мой пост.
...
Рейтинг: 0 / 0
11.10.2005, 17:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318081
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChВопрос на миллион долларов :). Вы знаете, я, как ни странно, буду вызывать их методы :).

Да пожалйуста, только сделайте хранилище объектов так, чтоб оно обрабатывалось не набором универсальных хп с динамикой!
...
Рейтинг: 0 / 0
11.10.2005, 17:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318089
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Ваши предложения?
...
Рейтинг: 0 / 0
11.10.2005, 17:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318100
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Если система велика и достаточно сложна, то быть может разработка интерпретатора (говоря по-другому,встроенного языка) для нее может быть рассмотрено, как поиск 3-го пути?
PS
...
Рейтинг: 0 / 0
11.10.2005, 17:37
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318101
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChВаши предложения?

Этого не хватает :

pkarklinчтоб оно обрабатывалось не набором универсальных хп с динамикой
...
Рейтинг: 0 / 0
11.10.2005, 17:37
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318107
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
авторЭтого не хватает
Нет, этого не хватает, т.к. вы предлагаете мне выкинуть то, что есть не предоставляя никаких аргументов в пользу этого, а не можете ответить на вопрос, что применять вместо этого.
...
Рейтинг: 0 / 0
11.10.2005, 17:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318116
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh авторЭтого не хватает
Нет, этого не хватает, т.к. вы предлагаете мне выкинуть то, что есть не предоставляя никаких аргументов в пользу этого, а не можете ответить на вопрос, что применять вместо этого.

Какие аргументы Вам нужны?! То, что у меня клиент оперирует Объектом Документ в терминах ООП, а обработка в бд ведеться хранимыми процедурами без динамики. Вам привести исходники клиента и бд?!
...
Рейтинг: 0 / 0
11.10.2005, 17:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318117
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Тут просто обсуждение идет уже достаточно давно и чтобы вникнуть в суть надо предудущие несколько страниц прочитать :) Иначе все опять будет идти по кругу.
...
Рейтинг: 0 / 0
11.10.2005, 17:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318130
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinКакие аргументы Вам нужны?! То, что у меня клиент оперирует Объектом Документ в терминах ООП, а обработка в бд ведеться хранимыми процедурами без динамики. Вам привести исходники клиента и бд?!

Да я верю что у вас это делается. Как вы производте выборку этих объектов типа Документ? Тоже хранимой процедурой? А на каждый новый тип объекта создаете новые хранимые процедуры для выборки? И в каждой такой процедуре проверяете например права на выборку определенных объектов?
Или такие права у вас проверяются на клиенте? А при изменении набора хранимых атрибутов объекта переписываете эти хранимые процедуры?
...
Рейтинг: 0 / 0
11.10.2005, 17:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318136
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChТут просто обсуждение идет уже достаточно давно и чтобы вникнуть в суть надо предудущие несколько страниц прочитать :) Иначе все опять будет идти по кругу.

Т.е. Вы считаете, что я начал читать с конца?!
...
Рейтинг: 0 / 0
11.10.2005, 17:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318139
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Мне кажется, что введение интерпретатора способно примирить многое, особенно в плане производительности; скажем, сразу же формируем требования к некоторой специфике, когда именно, в каких случаях нужно снабжать (и какие именно) объекты нашего интерпретатора префиксами Client.Variable1, Server.Function1 и т.д. Т.е. пусть все остается на своих местах: Серверу - серверово, а клиенту - клиентское.
...
Рейтинг: 0 / 0
11.10.2005, 17:47
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318153
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
И все-таки, Вы не ответили на вопрос, зачем Вам на клиенте полноценные объекты?
...
Рейтинг: 0 / 0
11.10.2005, 17:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318162
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
авторИ все-таки, Вы не ответили на вопрос, зачем Вам на клиенте полноценные объекты?

Вы что, издеваетесь?
...
Рейтинг: 0 / 0
11.10.2005, 17:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318168
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
По-моему в процедуру достаточно передать в качестве параметра идентификатор объекта, а процедура в базе найдет те необходимые доп параметры, которые Вы вытащили на клиента.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 17:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318170
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChКак вы производте выборку этих объектов типа Документ? Тоже хранимой процедурой?

У меня все делается через хп!

VladiChА на каждый новый тип объекта создаете новые хранимые процедуры для выборки?

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

VladiChИ в каждой такой процедуре проверяете например права на выборку определенных объектов? Или такие права у вас проверяются на клиенте?

Уу... Разграничение прав доступа - это отдельная пестня. И, естественно, это делается не на клиенте. Каждый документ имеет ранг доступности (общедоступный, секретный и т.п.). Для каждой роли определен ранг, документы с которым и "ниже" член роли может иметь право видеть. Кроме того, существуют дополнительные ограничения на права редактирования видимых документов. Долго можно расказывать...

VladiChА при изменении набора хранимых атрибутов объекта переписываете эти хранимые процедуры?

Если в процессе работы вдруг появляется потребность в новом аттрибуте, то потребуется:
1. Изменение структуры хранения
2. Изменения алгоритма обработки (тем самых хп)
3. Изменение клиента.
...
Рейтинг: 0 / 0
11.10.2005, 17:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318173
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
У меня на клиенте в объекте есть только те методы, которые дергает пользователь, если их пользователь не дергает, то они на клиенте не нужны
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 17:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318174
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну вот, уже веселее, и до конца дня рабочего полчаса - есть время ответить :))

Пример действительно плохой взят.
Потому что у всех тут (почти) он работает на чистом SQL.

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

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

авторК примеру, я просто выбираю все "товары", в том числе и унаследованные.
Выражение для выборки строится наполовину в промежуточном слое, наполовину в СУБД, т.к. логика построения такого выражения достаточно сложная, а язык СУБД для этого очень слабо приспособлен.
Т.е. вы не можете select * from Товар написать прямо в ХП? Для этого городите непонятно что? А зачем? Я так и не понял.

авторЕсть свой язык для выборки объектов + набор универсальных хранимых процедур, в которые передаются "полураспарсенные" конструкции этого языка. Этими несколькими хранимыми процедурами генерится динамический SQL для выборки коллекции объектов.
Коллекции каких таких объектов? Почему так хитро? Почему не только SQL?

авторОбработка результата тоже производтся в промежуточном слое, на выходе получается коллекция объектов класса "Товар".
Зачем? Зачем вам обрабатывать это на клиенте? Зачем вообще обрабатывать? Вообще, не зная, что вы подразумеваете под коллекцией объектов, под самим объектом и т.д.

авторВ результате при добавлении любых новых систем ценообразования, любых специфических типов товаров, в клиентский код, который работал с коллекциями товаров не прийдется вносить никаких изменений.
Но если что сильно поменяется - придется.
У нас же на клиента не надо вносить ничег ни до, ни после, вообще клиенту фиолетово.

авторРазумеется. У меня логика кэширования зависит от логики приложения, а не от логики СУБД.
Так и был вопрос - чего кэшируете?

авторОчень не хочется здесь всю архитектуру приложения описывать, т.к. кучу времени займет, но поверьте, одним SQL-ем здесь не обойтись... Он используется на клиенте для выборки коллекций объектов с использованием связей между сущностями. Связи также описаны в метаданных. Помимо обычных атрибутов, хранящихся в таблицах, есть т.н. "расширенные" атрибуты, хранящиеся вертикально в отдельной таблице, в принципе по ним также может осуществляться сортировка и поиск. Если это все писать на чистом SQL... Сложновато получается и непонятно, мягко говоря. На клиенте меня не интересуют таблицы и view, меня интересуют сущности в моей системе, в терминах этих сущностей и работают выборки с использованием своего языка.
Да и выборки получаются не очень простые, на 2-3 рекордсета в среднем, их приведение к коллекции объектов осуществляется отдельно, поэтому сам результат выполнения SQL-выражения мне на клиенте тоже неинтересен.
Эээээ.....
Зайдите на www.ozon.ru, возьмите любой товар. На товаре до фига чего есть - авторы, страницы, издатель, обложка, производитель, актеры, описания, комментарии, аналоги и еще туева хуча всякой белиберды, которая зависит от типа товара, и все это хранится не в тексте (как на html-странице красиво), а в атрибутах товара - единичных, множественных, привязанных других объектах и т.д. и т.п. и на клиенте выглядит ужасающе. И все это работает через СУБД. Нет, конечно на клиенте кое-чего тоже сделано, чтобы оно все показывалось как надо, но обрабатывается, связывается и т.д. оно только в СУБД, через sql.
Никаких проблем таких, чтобы решать это чем-то еще, нет.

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

автор
>>А зачем Вам на клиенте нужны полноценные объекты? Что Вы с ними делать будете на клиенте?
Вопрос на миллион долларов :). Вы знаете, я, как ни странно, буду вызывать их методы :). Причем у объекта типа SpecificThing1 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething1 с передачей параметра param1, где param1 - это дополнительное свойство SpecificThing1. А у объекта SpecificThing2 метод ComputeSomething будет вызывать в результате хранимую процедуру p_ComputeSomething2 с передачей параметра param2, где param2 - это дополнительное свойство SpecificThing2.
Свойства param1 и param2 выбираются из полей таблиц SpecificThing1 и SpecificThing2, т.е. в таблице Things не присутствуют. Классы SpecificThing1 и SpecificThing2 унаследованы от класса Thing, данные которого хранятся в таблице Things. А select * from Things мне в этом случае вернет нечто непонятное.
Я выше написал, как оно работает.
Вам что, проблема сделать одну ХП, которая будет понимать, какой метод дернуть исходя из типа товара? Для этого вы городите городушки? Только для этого???!!!
Или вы что-то скрываете? :)

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 17:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318188
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторДа я верю что у вас это делается. Как вы производте выборку этих объектов типа Документ? Тоже хранимой процедурой? А на каждый новый тип объекта создаете новые хранимые процедуры для выборки? И в каждой такой процедуре проверяете например права на выборку определенных объектов?
Или такие права у вас проверяются на клиенте? А при изменении набора хранимых атрибутов объекта переписываете эти хранимые процедуры?
Да, именно так все и делается, и права в СУБД проверяются.
Чем достигается самая лучшая: скорость работы, простота, универсальность, понятность, неперегруженность.... ну может еще чего забыл

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 18:01
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318192
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Да, и все же, мы тут видать все не поняли, поэтому повторю и я:

И все-таки, Вы не ответили на вопрос, зачем Вам на клиенте полноценные объекты?

-- Tygra's --
...
Рейтинг: 0 / 0
11.10.2005, 18:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318201
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Уу... Как у вас все запущено... Это я говорю про поддержку и развитие такой системы. Возможно, быстродействие у вас на высоте, но потеряв не очень много в быстродействии можно сильно выиграть в минимизации необходимого для расширения/поддержки системы кода. Один из методов - это как раз то, от чего вы мне посоветовали отказаться. Причем в обработку там подключаются тоже только нужные таблицы, просто тот же SQL будет генерироваться автоматически, а не вручную.

pkarklinЕсли в процессе работы вдруг появляется потребность в новом аттрибуте, то потребуется...

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

Разграничение прав доступа проверяется тоже в этих универсальных процедурах.
...
Рейтинг: 0 / 0
11.10.2005, 18:06
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318206
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Возьмем документ, какие у него есть методы для пользователя?

Посмотреть
Редактировать
Изменить статус
Распечатать
Удалить

Зачем в объекте на клиенте нужен метод рассчитать цену, если пользователь всего навсего вызовет метод изменить статус, у которого будет только 2 параметра: идентификатор объекта и идентификатор статуса

Все остальное работает в базе
Данный метод (виртуальный) по типу документа найдет метод изменения статуса и вызовет его передав 2 параметра (смотри выше).

Метод изменения статуса откроет транзакцию и вызовет событие OnChangeStatus с теми же двумя параметрами.

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

Виртуальный метод по типу товара определит конкретную процедуру начисления цены и вызовет ее с 2 параметрами: идентификатор товара и output параметр цена и вернет код 0, если все в порядке

Метод изменения статуса если все ОК запишет новый статус документу и закроет транзакцию

Вот и все. Понятное тех. задание?


--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318228
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Я уже давно не умею проектировать необъектно, но самое главное я просто не представляю что можно делать на клиенте, кроме манипуляций формами.

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318229
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
[quot Old Nick]У меня на клиенте в объекте есть только те методы, которые дергает пользователь, если их пользователь не дергает, то они на клиенте не нужны
[quot]

Прочитайте еще раз внимательно ... Пользователь дергает эти методы... Эти методы реализуются по-разному у разных типов объектов, но пользователь их дергает одинаково. Для выполнения этих методов объекту нужны атрибуты, загружаемые з базы. Может быть я конечно непонятно пишу, не знаю... Но мне почему-то кажется, что дело не во мне, просто кое-кто упорно не желает понимать простейших вещей. Разумеется можно дернуть одну ХП, которая внутри определит тип товара и дернет другую ХП. При добавлении нового типа товара вам нужно будет переписывать эту ХП. Но ООП для того и вводилось, чтобы не переписывать постоянно один и тот же код. Переписывать гораздо проблематичнее, чем написать новый, если вы этого не понимаете, то просьба сначала пойти почитать основы ООП, потом возвращайтесь и продолжим разговор.
...
Рейтинг: 0 / 0
11.10.2005, 18:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318240
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
При добавлении нового типа товара базовую виртуальную процедуру менять не нужно, она же виртуальная, ей фиолетово, какие типы товара будут, а делается это так:

declare @ProcName varchar(128)

declare Walker cursor local fast_forward for
select ProcName = o.name
from sysobjects o
join
ObjectTypeTree t
on ‘sp’ + t.ParentType + ‘_CalcPrice’ = o.name
and o.xtype = ‘P’
and t.Type = @Type
order by t.Level desc

open Walker
fetch next from Walker into @ProcName
while @@fetch_status = 0
begin
exec @Err = @ProcName @ThingId
fetch next from Walker into @ProcName
end
close Walker
deallocate Walker


--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318241
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraТак и был вопрос - чего кэшируете?
Мне честно говоря надоело повторять, можете прочитать выше парой страниц, пишу в последний раз: кэшируются например метаданные для типов объектов + некоторые наиболее часто используемые выборки системных объектов. Полагаться для этого на кэш СУБД нет никакого резона.

tygraВаша архитектура ничем не отличается от других - ну если только плохо построена под sql изначально :)
Еще одно необоснованное высказывание?

Old NickЗачем в объекте на клиенте нужен метод рассчитать цену
Я не знаю, у меня таких методов и в помине не было.

Old NickЯ уже давно не умею проектировать необъектно, но самое главное я просто не представляю что можно делать на клиенте, кроме манипуляций формами.
Так у вас формы оторваны от данных вообще? Чтобы получать/изменять данные наверное что-то нужно еще кроме манипуляции формами?
...
Рейтинг: 0 / 0
11.10.2005, 18:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318246
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Old NickПри добавлении нового типа товара базовую виртуальную процедуру менять не нужно, она же виртуальная, ей фиолетово, какие типы товара будут, а делается это так

Вы всерьез считаете что эмуляция ООП в базе данных это лучший подход к проектированию системы? Мда...
...
Рейтинг: 0 / 0
11.10.2005, 18:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318252
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Извиняюсь. Не тот пример.

declare @ProcName varchar(128)

select top 1 @ProcName = o.name
from sysobjects o
join
ObjectTypeTree t
on ‘sp’ + t.ParentType + ‘_CalcPrice’ = o.name
and o.xtype = ‘P’
and t.Type = @Type
order by t.Level desc

exec @Err = @ProcName @ThingId

Этот код написан в виртуальной процедуре.
Он найдет процедуру конкретную. Если у наследника не будет своей процедуры, то вызовется процедура родителя

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:26
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318256
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Не нравится эмуляция, возьмите Каше
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318267
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Либо Вы в SQL эмулируете объекты, либо в ООП эмулируете SQL

Что лучше? Лучше Каше. Но пока я не нашел заказчиков, а если будут, то обязательно буду создавать объекты в Каше и писать у них методы на SQL
--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
11.10.2005, 18:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318273
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Old NickЛибо Вы в SQL эмулируете объекты, либо в ООП эмулируете SQL
Ну большинство высказавшихся тут считает что ООП нужно только чтобы формочки рисовать, так что хоть один свежий взгляд на проблему. Хотя я не эмулирую SQL при помощи ООП, ООП - это просто еще один уровень абстракции над базой данных.
...
Рейтинг: 0 / 0
11.10.2005, 18:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318354
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiCh tygraТак и был вопрос - чего кэшируете?
Мне честно говоря надоело повторять, можете прочитать выше парой страниц, пишу в последний раз: кэшируются например метаданные для типов объектов + некоторые наиболее часто используемые выборки системных объектов. Полагаться для этого на кэш СУБД нет никакого резона.

Про метаданные на клиенте, вам виднее, надо оно или нет, при логике в СУБД имхо такой вопрос просто не стоит.

Про выборки часто используемых системных объектов я не очень понял, что вы называете системными объектами- АцессКонтролЛисты и права пользователей? редко-меняемые справочники?

Имхо с точки зрения производительности, скорей всего вы не сэкономили на таком кэшировании ничего, может быть чуть-чуть сетевого трафика. Джойнами с маленькими справочниками производительность СУБД сильно не подсадишь.

Другой вопрос, что вам пришлось их закэшировать, т.к. ваша объектная архитектура вылилась в мощный поток мелких обращений к СУБД за данными из этих самых "маленьких справочников", что и привело к тормозам.

Права доступа закэшированные в апп-сервере, опять-таки имхо, не слишком удобны. При любом их изменении придется либо пинать все апп-сервера либо ждать пока они авто-обрефрешатся.

Ну чтож сами придумываем проблемы- сами решаем - весело :)
...
Рейтинг: 0 / 0
11.10.2005, 19:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318376
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
А вы как, сами решили что я делаю, сами покритиковали, сами сделали вывод?
Разумеется, права доступа не кешировались. Если вам кажется, что вопрос о кэшировании метаданных при логике в СУБД не стоит, то вы ошибаетесь. СтоИт, да еще как.
Моя объектная архитектура построена так, чтобы как раз минимизировать количество обращения к СУБД, с чем успешно и справляется в том числе и за счет кэширования.
Проблемы к счастью мне придумывать не надо, их и без придумывания достаточно.
...
Рейтинг: 0 / 0
11.10.2005, 19:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318423
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
2tygra:
Я уже писал, повторю еще раз. А товсе требуют примера ООП в БЛ. Вот пожалуйста. Случай простейший. Опишите как это будет работать на простых ХП и после этого мы можем сравнить результаты.


Давайте представим, что существует вот такая СУБД (объектно-реляционная):
1. Возможность создавать классы, соответствующие данным
2. Методы классов можно писать на языке а-ля С# + SQL
3. Наследование автоматически включает хранимые [Stored] поля базовых классов, а таблица задается "верхним" классом (для примера ниже все документы, имеющие в базовом списке DocumentBase будут иметь поля Number и Status, а кто унаследован от DocumentSign - Number, Status и SignedBy).


Тогда для вымышленной системы документооборота можно иметь следующую иерархию:
class DocumentBase //базовые свойства документов
{
[Stored]
string Number;
[Stored]
int Status;
......
}

class DocumentSign : DocumentBase //базовый класс для документов, треб.
{ // подпись

[Stored]
SignedBy: CPerson;

method Sign( person : CPerson)
{
SignedBy = person;
Save();
}
}
......

Тогда в коде приложения на РМ, где происходит операция подписи документа, независимо от типа документа ( накладная, заявление по собств. желанию ....)
выполняется код:

(DocumentSign)currentDocument.Sign( currentUser);


Хотелось бы увидеть, как может выглядеть структура данных + ХП для аналогичный случая на обычной системе КС + РСУБД.
...
Рейтинг: 0 / 0
11.10.2005, 19:53
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318427
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChА вы как, сами решили что я делаю, сами покритиковали, сами сделали вывод?
Разумеется, права доступа не кешировались. Если вам кажется, что вопрос о кэшировании метаданных при логике в СУБД не стоит, то вы ошибаетесь. СтоИт, да еще как.
Моя объектная архитектура построена так, чтобы как раз минимизировать количество обращения к СУБД, с чем успешно и справляется в том числе и за счет кэширования.
Проблемы к счастью мне придумывать не надо, их и без придумывания достаточно.
Ладно извиняюсь я сужу по системам которые я видел, говорить за вашу - это я погорячился.

А вы могли бы конкретизировать, зачем кэшировать метаданные при логике в СУБД. Или вы про АДО,ДАО,ЛинкедСервера? Это да - любят они метаданные закачать :) Ну так их с умом надо использовать просто.

Вы не могли бы, кстати, ответить на вопросы, которые я задавал на странице 6 топика?
...
Рейтинг: 0 / 0
11.10.2005, 19:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318432
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеевVoDA,
насчет того, что SQL сервер построит выборку быстрее нет сомнений, это его хлеб. Но что дальше будете делать с выборкой - пересылать клиентам? И сервер будет заниматься её обработкой?
Здесь я с Вами принципиально расхожусь. Я за сервера приложений и распределенные вычисления.
Достаточно долго разрабатывал системы управления тех. процессами. Там эти споры заглохли давно - контроллеры имеют право на существование. Но разницу между этими областями понимаю.
Суважением, Владимир.А что до этого системы управления тех.процессами писали на СУБД? ;) Если вы думаете, что вас здесь убеждают весь софт в мире и особенно АСУТП переписать на TransactSQL - то это не так.
Обсужение вертится вокруг учетных систем предприятий разного размера и сложности.

ВМоисеевDrKonito.
Спасибо за перенос акцентов. Меня интересуют не споры, что лучше двухзвенка-многозвенка, а варинты построения реальных многозвенных систем.
Но на Ваши прямые вопросы по существу я не могу дать столь же прямые и исчерпывающие вопросы. И вот почему - я разрабатываю один из возможных вариантов построения прототипов (типовых моделей) многозвенных защищенных информационных систем для обслуживания многих(тысяч) клиентов. Разрабатываю один и достаточно много лет.

Предпоследний вариант был для DCOM, но три года назад узнал о возможностях .Net и все свои знания и опыт попытался воплотить в при построении реальной системы в данной среде. Отчет, о то что и как получилось опубликовано здесь (повторяюсь): http://www.gotdotnet.ru/LearnDotNet/NETFramework/125377.aspx
(первая и третья редакции).

Прочитал я вашу статью про прототип приложения. Имхо такой подход укладывается в то, что tygra назвал "толстый драйвер".
Насколько я понял в вашей системе бизнес-логическая процедура (в моем понимании) только одна и она собственно находится на сервере СУБД. Так что преимущества выноса бизнес-логики в отдельный слой этот прототип не иллюстирует.
Имхо вопросы аутентификации, авторизации, шифрования в учетных системах ну никак не отнесешь к бизнес-логике.
...
Рейтинг: 0 / 0
11.10.2005, 19:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318436
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
авторdeclare @ProcName varchar(128)

select top 1 @ProcName = o.name
from sysobjects o
join
ObjectTypeTree t
on ‘sp’ + t.ParentType + ‘_CalcPrice’ = o.name
and o.xtype = ‘P’
and t.Type = @Type
order by t.Level desc

exec @Err = @ProcName @ThingId

А вам не кажется, что данная логика значительно лучше реализуется на ОО языках вместо того, чтобы городить это на сервере. Ведь именно про такую обвязку и говорил Д. Сорокин в первых постах.
Как у вас вызвается метод базового класса? Тоже через такой поиск? Зачем???
Если это пример того, как "снижаются" расходы на разработку - то я молчу. Релиазовывать С++ на T-SQL, да еще и так, что это становится делом ВСЕХ разработчиков системы - это что-то. В вашей реализации любой девелопер, разрабытвающий БЛ должен знать, что при добавлении метода ему нужно сделать "виртуальный", в нем пробежаться по таблице типов, выбрать нужный по имени и его вызвать. А если потом ошибиться на одну букву в названии метода для типа - то еще и ошибку получить. Великолепно.
...
Рейтинг: 0 / 0
11.10.2005, 20:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318456
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Вообще-то это старая версия.

В новой используются метаданные не сервера, а системы и писать такую конструкцию не нужно, для этого есть макрос. Кроме того ошибиться в буковке класса невозможно, так методы создаются из системы и имя класса там не фигурирует
...
Рейтинг: 0 / 0
11.10.2005, 20:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318521
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito,
>А что до этого системы управления тех.процессами писали на СУБД?

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

>Прочитал я вашу статью про прототип приложения. Имхо такой подход укладывается в то, что tygra назвал "толстый драйвер".

Если Вам так более понятно, пусть будет "толстый драйвер", хотя я предпочитаю термины функциональные слои (звенья) и сервера приложений.
Для меня важно построить типовую модель распределенной вычислительной сети, основанную на .Net Remoting сервисах. Сервисы могут располагаться и на отдельных компьютерах (и несколько сервисов на одном компе), а могут и на ваших суперкомьютерах серверов данных.

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

MS SQL имеет относительный максимум призводительности по числу одновременно выполняемых запросов (не знаю как Oracle). Число серверов приложений в прототипе находится где-то рядом с этим максимумом. Причем сервер приложений открывает одно соединение с сервером данных и в дальнейшем не отпускает его.
Мне надо, что-бы все серверы приложений работали под одним аккаутом (строка соединения постоянна и не зависит от клиента). Поэтому выполняю аутентификацию клиента и построение клиентской сессии по полной схеме.

Я могу (стараюсь по крайней мере) проанализировать время выполнения запроса (группирую их) и дать возможность выполняться быстрым запросам, притормаживая долгоиграющие.

>Имхо вопросы аутентификации, авторизации, шифрования в учетных системах ну никак не отнесешь к бизнес-логике.

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

С уважением, Владимир.
...
Рейтинг: 0 / 0
11.10.2005, 22:13
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33318738
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChУу... Как у вас все запущено...

Например если в документе есть поля, которые надо выделять отдельно, но на бизнес-логику они никак не завязаны, зато по ним например может производиться поиск, то мне не придется изменять ничего, просто в конфигураторе описать новые поля.
...
Разграничение прав доступа проверяется тоже в этих универсальных процедурах.

Ой, дежавю... Вы 2С разработали?! Зачем, уже же есть 1С со всем известными ее проблемами?!
...
Рейтинг: 0 / 0
12.10.2005, 07:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319089
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Вот как так? Говоришь одно, спрашиваешь одно - отвечают другое.......

ООП А вам не кажется, что данная логика значительно лучше реализуется на ОО языках вместо того, чтобы городить это на сервере. Ведь именно про такую обвязку и говорил Д. Сорокин в первых постах.
Как у вас вызвается метод базового класса? Тоже через такой поиск? Зачем???
Нам не кажется.
А вы привели бы пример этого всего на ООП - а мы посмотрим, как прекрасно, когда БЛ зависит от клиента. Особенно если вдруг версии клиента разные. :))
Ну еще вам наверное интересно писать в клиенте кучу структур, вместо одной маленькой и простой ХП? А потом править там же, на клиенте - так? Или не так? А как? Хотелось бы пример.

ООП Если это пример того, как "снижаются" расходы на разработку - то я молчу. Релиазовывать С++ на T-SQL, да еще и так, что это становится делом ВСЕХ разработчиков системы - это что-то.
У вас очки не те одеты - вы о каком С++? Или ..а, понятно, вот почему ООП - вы же только на С++ умеет с данными работать, а на SQL кроме select * from table ничего боле не можете. Ну так ваши проблемы, что sql не родной.

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

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

VladiCh Пользователь дергает эти методы... Эти методы реализуются по-разному у разных типов объектов, но пользователь их дергает одинаково.
Ну конечно одинаково - одну ХП :) Только для того, чтобы ее дернуть, не надо городить городушки на клиенте - просто exec ChangeState @ID, @SID. И как бы логика не поменялась - всегда только этот вызов, с любого клиента, даже если у вас кроме ID и названия объекта ничего больше нет (естественно и никаких ООП).
авторДля выполнения этих методов объекту нужны атрибуты, загружаемые з базы.
Вот! А нам не нужно ничего загружать из базы - все там в ней самой и делается. Что проще?
VladiCh Может быть я конечно непонятно пишу, не знаю... Но мне почему-то кажется, что дело не во мне, просто кое-кто упорно не желает понимать простейших вещей.
Ну, мы просто не можем никак понять, зачем вам объекты со всеми их атрибутами и методами, которые как-то генерит какой-то специальный механизм. Почему непонятно - потому что непонятно, зачем делать сложнее, если можно проще, причем намного. Было бы у вас проще - мы бы другое говорили.

VladiCh Разумеется можно дернуть одну ХП, которая внутри определит тип товара и дернет другую ХП. При добавлении нового типа товара вам нужно будет переписывать эту ХП.
Ну если вы хотите - переписывайте.
Обычно не переписывают - одна базовая ХП имеет только механизм для разборки, что, кто, зачем и где дернуть, вся же обработка естественно для каждого типа товара написана отдельно. Но тут уж простор реализаций - кто алгоритмы хранит и потом обрабатывает, а кто и отдельные процедуры пишет.
Но сводится все к одному: дернули базовую ХП, она поняла тип, по типу определила, что исполнить, исполнила, отдала ответ. Все. Зачем тут ООП, да еще на клиенте? Зачем вообще для этого что-то на клиенте?

Я еще раз обозначу проблему: зачем вам объекты? Ну приведите пример объекта, примерное описание кода, который делает объект на клиенте и т.д.
Потому что пока все-равно не понятно - у нас сделано все намного проще, а работает так же. Смысл делать сложнее?

Может рассказать и про мой "механизм", так, для информации? Может...

-- Tygra's --
...
Рейтинг: 0 / 0
12.10.2005, 10:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319170
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
ASCRUSНу давайте уважаемые адепты 3-х звенок спустимся наконец на землю и на конкретных примерах от вас услышим, что же это за бизнес-логика такая у вас сложная, что она выльется в тысячи хранимых процедур с большим кол-вом кода, да еще который из за изменения ТЗ весь почему то лопатить придется ?
Спор для себя считаю бессмысленным, хотя аргументы интерсны. Приведу только пример 3-х (много) звенки. Система регистрации пользователей. Веб-интерфейс - запрос пользователя о своих данных.
1. Обработка - проверка корректности данных по базе данных и далее
2. Созадть учетную запись в Active Directory в нужном домене (на основании данных из базы данных), занести в нужные группы (на основании должностей, категорий, ролей и т.п.)
3. Создать личную папку на файловом сервере и дать на нее права. Создать при необходимости папку отдела на сервере и дать на нее права вновь созданной учетной записи
4. Создать папку на другом сервере и дать на нее права
5. Создать запись в базе данных
Ну ладно, по здешним парвилам веб-приложение не считается отдельным слоем. Ладно - сравнение на корректность 1 и п.5. можно делать или там же или в ХП. Теоертически какжется где-то мелькала информация, что можно даже создать учетную здапись из СУБД (но кажется речь шла исключительно о MS SQL - тут не буду спорить).
НО п.3 и п.4. Можно сделать только с помощью приложения, работающего на тех же серверах, где файловые серверы и приложения, конечно, не SLQ. У нас на С++, возможно и на функциональных написать, только не понятно, чем они здесь лучше обычного С++, или просто С.
...
Рейтинг: 0 / 0
12.10.2005, 10:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319211
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
MainFrameНО п.3 и п.4. Можно сделать только с помощью приложения , работающего на тех же серверах, где файловые серверы и приложения, конечно, не SLQ. У нас на С++, возможно и на функциональных написать, только не понятно, чем они здесь лучше обычного С++, или просто С.Спорно. У меня, как пример, закачкой данных на сервер занимается сам сервер.

Реализованно очень просто - сервер запускает шелл-команду и все...

PS это не панацея, а просто пример того, что приложением может выступать и сам SQL-сервер.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
12.10.2005, 11:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319222
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrameПриведу только пример 3-х (много) звенки. Система регистрации пользователей. Веб-интерфейс - запрос пользователя о своих данных.

Эээ... Интересный, пример, однако... Особенно в плане темы топика "Сервер приложений". И где тут бизнес-логика?! Голимое администрирование...

авторНО п.3 и п.4. Можно сделать только с помощью приложения, работающего на тех же серверах, где файловые серверы и приложения, конечно, не SLQ.

И какие проблемы вызвать это приложение на удаленном сервере?! про расширенные хп вы слышали? Которые можно на том же С++ написать и дергать их в СУБД.
...
Рейтинг: 0 / 0
12.10.2005, 11:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319248
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
MainFrame ASCRUSНу давайте уважаемые адепты 3-х звенок спустимся наконец на землю и на конкретных примерах от вас услышим, что же это за бизнес-логика такая у вас сложная, что она выльется в тысячи хранимых процедур с большим кол-вом кода, да еще который из за изменения ТЗ весь почему то лопатить придется ?
Спор для себя считаю бессмысленным, хотя аргументы интерсны. Приведу только пример 3-х (много) звенки. Система регистрации пользователей. Веб-интерфейс - запрос пользователя о своих данных.

Позволю себе слегка изменить порядок действий
0. Первичная проверка правильности ввода клиентом (JavaScript)
MainFrame1. Обработка - проверка корректности данных по базе данных и далее
5. Создать запись в базе данных Выполняются в хранимой процедуре

MainFrame2. Созадть учетную запись в Active Directory в нужном домене (на основании данных из базы данных), занести в нужные группы (на основании должностей, категорий, ролей и т.п.)
3. Создать личную папку на файловом сервере и дать на нее права. Создать при необходимости папку отдела на сервере и дать на нее права вновь созданной учетной записи
4. Создать папку на другом сервере и дать на нее праваВыполняются скриптом/набором скриптов на WSH/bat/cmd/*nix shell, которые генерятся и запускаются на исполнение той же самой хранимой процедурой.

Кстати, как поведет себя приложение, действующее по описанному вами сценарию, в случае если п.5 по каким-либо причинам не выполнился и необходимо произвести откат транзакции?
...
Рейтинг: 0 / 0
12.10.2005, 11:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319293
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
VoDA MainFrameНО п.3 и п.4. Можно сделать только с помощью приложения , работающего на тех же серверах, где файловые серверы и приложения, конечно, не SLQ. У нас на С++, возможно и на функциональных написать, только не понятно, чем они здесь лучше обычного С++, или просто С.Спорно. У меня, как пример, закачкой данных на сервер занимается сам сервер.

Реализованно очень просто - сервер запускает шелл-команду и все...

PS это не панацея, а просто пример того, что приложением может выступать и сам SQL-сервер.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!

Попробуйте создать папки на файловых серверах в Windows , находясь где-нибудь в другом месте кроме самого сервера и назначить квоты учетным записям на этом сервере.
...
Рейтинг: 0 / 0
12.10.2005, 11:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319305
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
pkarklin MainFrameПриведу только пример 3-х (много) звенки. Система регистрации пользователей. Веб-интерфейс - запрос пользователя о своих данных.

Эээ... Интересный, пример, однако... Особенно в плане темы топика "Сервер приложений". И где тут бизнес-логика?! Голимое администрирование...

авторНО п.3 и п.4. Можно сделать только с помощью приложения, работающего на тех же серверах, где файловые серверы и приложения, конечно, не SLQ.

И какие проблемы вызвать это приложение на удаленном сервере?! про расширенные хп вы слышали? Которые можно на том же С++ написать и дергать их в СУБД.

1.Речь от сревера приложений плавно перетекла к многоуровневым приложением, поэтому и пример приведен приложения, где многокомпонентность необходимая вещь.
2. А при чем тут расширение. Приложение должно работать на файловом сервере (сервер базы данных - это свосем другой сервер), иначе оно не может задать квоты учетной записи.
...
Рейтинг: 0 / 0
12.10.2005, 11:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319313
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
PL99 MainFrame ASCRUSНу давайте уважаемые адепты 3-х звенок спустимся наконец на землю и на конкретных примерах от вас услышим, что же это за бизнес-логика такая у вас сложная, что она выльется в тысячи хранимых процедур с большим кол-вом кода, да еще который из за изменения ТЗ весь почему то лопатить придется ?
Спор для себя считаю бессмысленным, хотя аргументы интерсны. Приведу только пример 3-х (много) звенки. Система регистрации пользователей. Веб-интерфейс - запрос пользователя о своих данных.

Позволю себе слегка изменить порядок действий
0. Первичная проверка правильности ввода клиентом (JavaScript)
MainFrame1. Обработка - проверка корректности данных по базе данных и далее
5. Создать запись в базе данных Выполняются в хранимой процедуре

MainFrame2. Созадть учетную запись в Active Directory в нужном домене (на основании данных из базы данных), занести в нужные группы (на основании должностей, категорий, ролей и т.п.)
3. Создать личную папку на файловом сервере и дать на нее права. Создать при необходимости папку отдела на сервере и дать на нее права вновь созданной учетной записи
4. Создать папку на другом сервере и дать на нее праваВыполняются скриптом/набором скриптов на WSH/bat/cmd/*nix shell, которые генерятся и запускаются на исполнение той же самой хранимой процедурой.

Кстати, как поведет себя приложение, действующее по описанному вами сценарию, в случае если п.5 по каким-либо причинам не выполнился и необходимо произвести откат транзакции?
Ответ уже дан. Система Windiows, приложение работает только на файловом сервере ввиду необходимости задавать квоты.
...
Рейтинг: 0 / 0
12.10.2005, 11:32
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319318
vialexis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vialexis
Гость
MainFrameПопробуйте создать папки на файловых серверах в Windows , находясь где-нибудь в другом месте кроме самого сервера и назначить квоты учетным записям на этом сервере.

Тут вот написано как сделать:
http://www.microsoft.com/technet/scriptcenter/topics/win2003/quotas.mspx

Учитывая поддержку Automation в T-SQL... Легко!
...
Рейтинг: 0 / 0
12.10.2005, 11:33
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319336
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrame1.Речь от сревера приложений плавно перетекла к многоуровневым приложением, поэтому и пример приведен приложения, где многокомпонентность необходимая вещь.
2. А при чем тут расширение. Приложение должно работать на файловом сервере (сервер базы данных - это свосем другой сервер), иначе оно не может задать квоты учетной записи.

1. Ок. Согласен.
2. Ну так и пусть себеработает. А запускать его будет расширенная хп.
...
Рейтинг: 0 / 0
12.10.2005, 11:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319381
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
vialexis MainFrameПопробуйте создать папки на файловых серверах в Windows , находясь где-нибудь в другом месте кроме самого сервера и назначить квоты учетным записям на этом сервере.

Тут вот написано как сделать:
http://www.microsoft.com/technet/scriptcenter/topics/win2003/quotas.mspx

Учитывая поддержку Automation в T-SQL... Легко!
Скорее всего да, только сам WMIService будет работать все равно на файловом сервере и сделает установку вместо Вас. Но он-то тоже будет частью вашей системы. Вы просто используете для установки не свое приложение, а существующий com объект на файловом сервере
...
Рейтинг: 0 / 0
12.10.2005, 11:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319451
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
Для разнообразия приведу еще один пример. Система тестирования. Тест, который предпоалагается пройти, является адаптационным. Т.е. в тесте есть определенные вопросы , которые являются подмножеством общего числа вопросов. И эти вопросы нужно показываться в некотором порядке, который заивист от ответов пользователя.
Приложение вебовское - J2EE.
Вариантов решения много.

1. Можно каждый раз, обработать ответ и выбирать из базы только тот вопрос, который нужно по результатам ответ показать. Сто вопросов - сто обращений к базе. ДВести пользователей одновременно тестируются - много обращений.
2. Можно выбрать один раз подмнождество. Потом из него выбирать тот, который соответсвует ответу на предыдущий. Обращений к базе меньше в сто раз. Нагрузка ложиться на сервер приложений.

можно и другое придумать.

Однозначаного лучшего решения тут нет, как мне кажется. По собственному опыту могу скзаать, что при большом числе пользователей выгоднее второй вариант, но наступает момент, когда отсутсвие нормальной сборки мусора (и кое какие другие причины) приводит к необходимости распределять нагрузку сервера приложений. НО и первый вариант не выход. На нем производительность недопустимая.
...
Рейтинг: 0 / 0
12.10.2005, 11:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319492
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrame НО и первый вариант не выход. На нем производительность недопустимая.

Это единственно правильный выход, IMHO. А вот для повышения производительности есть множество путей...
...
Рейтинг: 0 / 0
12.10.2005, 12:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319497
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
pkarklin MainFrame1.Речь от сревера приложений плавно перетекла к многоуровневым приложением, поэтому и пример приведен приложения, где многокомпонентность необходимая вещь.
2. А при чем тут расширение. Приложение должно работать на файловом сервере (сервер базы данных - это свосем другой сервер), иначе оно не может задать квоты учетной записи.

1. Ок. Согласен.
2. Ну так и пусть себеработает. А запускать его будет расширенная хп.
Разве важно кто кого запускает? Важно , что логику работы программы реализуют совершенно разные приложения, работающие на разных серверах. Это если о многозвенной говорим. А кто кого запустил - это же не имеет значение. Мне как раз в этом всем нравиться, что нет четко выраженного сревера и клиента. Но это лирика.
...
Рейтинг: 0 / 0
12.10.2005, 12:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319501
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
MainFrameСкорее всего да, только сам WMIService будет работать все равно на файловом сервере и сделает установку вместо Вас. Но он-то тоже будет частью вашей системы. Вы просто используете для установки не свое приложение, а существующий com объект на файловом сервереГм... Совершенно верно! И как это я, предлагая генерить скрипт, упустил из виду тот момент что записывать его в дисковый файл будет операционная система. Несомненно, без многозвенки, при разработке абсолютно любого приложения, не обойтись :-)
...
Рейтинг: 0 / 0
12.10.2005, 12:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319505
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
pkarklin MainFrame НО и первый вариант не выход. На нем производительность недопустимая.

Это единственно правильный выход, IMHO. А вот для повышения производительности есть множество путей...

Возможно, нам они не все известны, более того, точно не все. Но и Вы не преддложили решения, а многоточия все ставить умеют.
...
Рейтинг: 0 / 0
12.10.2005, 12:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319511
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
автор1. Можно каждый раз, обработать ответ и выбирать из базы только тот вопрос, который нужно по результатам ответ показать. Сто вопросов - сто обращений к базе. ДВести пользователей одновременно тестируются - много обращений.


Гм.... если обращение к базе это:
Коннект-селект-дисконнект, то будет тяжело, но если запросы делать по существующему соединению, будет гараздо быстрее. А руками писать джоины и перебор вопросов, вместо того, чтобы использовать уже написанное + можно индексы подвязать, это ИМХО мазахизм.
...
Рейтинг: 0 / 0
12.10.2005, 12:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319537
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrameВозможно, нам они не все известны, более того, точно не все. Но и Вы не преддложили решения, а многоточия все ставить умеют.

Решения по оптимизации... Без какой-либо конретики в симптомах... Мдя...

Кстати...


MainFrameОбращений к базе меньше в сто раз. Нагрузка ложиться на сервер приложений.

Ну и в чем "фишка" такого, с позволения сказать, распределения?! Вместо одного сервера, нужно два! Придеться реализовывать на сервере механизм кэширования, что уже реализовано в самой СУБД?! Зачем эти городушки?!
...
Рейтинг: 0 / 0
12.10.2005, 12:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319548
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
Terrorist автор1. Можно каждый раз, обработать ответ и выбирать из базы только тот вопрос, который нужно по результатам ответ показать. Сто вопросов - сто обращений к базе. ДВести пользователей одновременно тестируются - много обращений.


Гм.... если обращение к базе это:
Коннект-селект-дисконнект, то будет тяжело, но если запросы делать по существующему соединению, будет гараздо быстрее. А руками писать джоины и перебор вопросов, вместо того, чтобы использовать уже написанное + можно индексы подвязать, это ИМХО мазахизм.
Можно и индексы, но в силу определенных причин (удовлетворение некоторой спецификации) на те данные, которые участвуют в правилах адаптационного теста индексы привзяать нельзя (они привязаны к другим данным, которые используются в других ситациях). Данные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?
...
Рейтинг: 0 / 0
12.10.2005, 12:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319558
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrameДанные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?

И опять мы приходим к тому, что просчеты в проектировании структуры хранения выливаются в дополнительные навороты с сервером приложений и т.п. Печально все это... :(
...
Рейтинг: 0 / 0
12.10.2005, 12:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319569
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
pkarklin MainFrameВозможно, нам они не все известны, более того, точно не все. Но и Вы не преддложили решения, а многоточия все ставить умеют.

Решения по оптимизации... Без какой-либо конретики в симптомах... Мдя...

Кстати...


MainFrameОбращений к базе меньше в сто раз. Нагрузка ложиться на сервер приложений.

Ну и в чем "фишка" такого, с позволения сказать, распределения?! Вместо одного сервера, нужно два! Придеться реализовывать на сервере механизм кэширования, что уже реализовано в самой СУБД?! Зачем эти городушки?!

Хуже того - три! Так как приходится и севрер приложений распрделять. НО с тремя серверами задача решается - достигается нужная производительность при нужном числе пользователей. А с одним (было у нас, поэтому есть с чем сравнить), не решается никак. Проивзодительность недопустимая.
...
Рейтинг: 0 / 0
12.10.2005, 12:22
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319583
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
pkarklin MainFrameДанные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?

И опять мы приходим к тому, что просчеты в проектировании структуры хранения выливаются в дополнительные навороты с сервером приложений и т.п. Печально все это... :(
Просчеты это были или нет не будем обсуждать. Во-первых, это не тема данного топика, во-вторых, поверьте, там были серьезные причины дял такого решения. И в ином варианте было еще больше минусов.
...
Рейтинг: 0 / 0
12.10.2005, 12:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319618
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
MainFrame
Данные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?


И опять мы приходим к тому, что просчеты в проектировании структуры хранения выливаются в дополнительные навороты с сервером приложений и т.п. Печально все это... :(

Полностью согласен. MainFrame , кто Вас заставлял поля по которым идет выборка засовывать в БЛОБ?
...
Рейтинг: 0 / 0
12.10.2005, 12:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319640
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinОй, дежавю... Вы 2С разработали?! Зачем, уже же есть 1С со всем известными ее проблемами?!
Предположение неверно. Соответственно вывод тоже неправильный.
Ну раз вы обладаете телепатическими способностями то опишите хотя бы пару-тройку проблем моей системы (проблемы 1С описывать не обязательно).
tygraНу, мы просто не можем никак понять, зачем вам объекты со всеми их атрибутами и методами, которые как-то генерит какой-то специальный механизм. Почему непонятно - потому что непонятно, зачем делать сложнее, если можно проще, причем намного. Было бы у вас проще - мы бы другое говорили.
Ну если после того, что я написал и некоторые другие участники обсуждения вы все никак не можете понять, то я думаю что обсуждать этот вопрос с вами дальше смысла нет. Это и так у меня отнимает кучу времени, чтобы приводить здесь еще начальный курс ООП. Почитайте какую-нибудь литературу полезную что ли, начиная от основ до "Паттернов проектирования" и например Фаулера "Архитектура корпоративных программных приложений". Вы же вроде в Озоне работаете, думаю с литературой проблем быть не должно :).
...
Рейтинг: 0 / 0
12.10.2005, 12:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319656
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
Terrorist
MainFrame
Данные извлекаются фактически из BLOB. и всякий раз снова и снова выбирать из BLOB искать внутри и выбать следующий?


И опять мы приходим к тому, что просчеты в проектировании структуры хранения выливаются в дополнительные навороты с сервером приложений и т.п. Печально все это... :(

Полностью согласен. MainFrame , кто Вас заставлял поля по которым идет выборка засовывать в БЛОБ?
Реальность заставила. потому что другиевопросы с BLOB решались на порядок быстрее (в другом месте и атм это было так же среьбзно) и во-вторых, какое имеет это значение? Как бы мы не индесировали - сто обращений к базе не сравним с одним. При этом структуры сложные, и даже если бы в этмо месте обошлись без BLOB теряли бы на другом после каждого обращения пришлось бы составлять сложную структуру - проще найти уже в созданных - поверьте, это на порядок быстрее. А все струткуры заполняются в самом начале, потом нужно находить только определенные поля. Т.е. мы в самом начале готовим все для отображения. и только говорим , что именно отображать. А там пришлось бы всякий раз не только к базе обращаться, но и из результата делать заготовку и только потом отображать - это долго.
...
Рейтинг: 0 / 0
12.10.2005, 12:37
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319665
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
DrKonitoА вы могли бы конкретизировать, зачем кэшировать метаданные при логике в СУБД. Или вы про АДО,ДАО,ЛинкедСервера? Это да - любят они метаданные закачать :) Ну так их с умом надо использовать просто.

Я говорю про свои метаданные - описание объектов, полей, методов, связей, иерархии наследования. База данных про это ничего не знает, это для нее такие же данные, как и все остальные, а для приложения это критически важные данные, к которым часто идут обращения.
...
Рейтинг: 0 / 0
12.10.2005, 12:39
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319756
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
MainFrame
Реальность заставила. потому что другиевопросы с BLOB решались на порядок быстрее (в другом месте и атм это было так же среьбзно) и во-вторых, какое имеет это значение? Как бы мы не индесировали - сто обращений к базе не сравним с одним. При этом структуры сложные, и даже если бы в этмо месте обошлись без BLOB теряли бы на другом после каждого обращения пришлось бы составлять сложную структуру - проще найти уже в созданных - поверьте, это на порядок быстрее. А все струткуры заполняются в самом начале, потом нужно находить только определенные поля. Т.е. мы в самом начале готовим все для отображения. и только говорим , что именно отображать. А там пришлось бы всякий раз не только к базе обращаться, но и из результата делать заготовку и только потом отображать - это долго.

А вот сто обращений к вашему серверу и к базе, вполне сопоставимы. И при правльном проектировании, думаю БД будет быстрее. И не совсем понятно, что значит "готовим все для отображения"? Есть текст для, например, вопроса. Что с ним сделать для отображения нужно, что бы он был готов? Пожарить? :)
...
Рейтинг: 0 / 0
12.10.2005, 12:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319820
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChНу раз вы обладаете телепатическими способностями то опишите хотя бы пару-тройку проблем моей системы (проблемы 1С описывать не обязательно).

Наличие DSQL - вот самая большая проблема.

Которая приводит к:
1. необходимости раздачи прав на таблицы (представления) = дыра в системе безопастности.
2. постоянная перекомпиляция хп, выполняющих это DSQL, что пагубно сказыватеся на производительности.
...
Рейтинг: 0 / 0
12.10.2005, 13:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319851
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
MainFrameХуже того - три! Так как приходится и сервер приложений распрделять. НО с тремя серверами задача решается - достигается нужная производительность при нужном числе пользователей.

Зачем мне распределять сервер приложений, если я могу "умощнить" сервер СУБД для необходимой производительности?!

MainFrameКак бы мы не индесировали - сто обращений к базе не сравним с одним.

Конечно, чисто арифметически 100 > 1. Но Вы в своей арифметике забываете еще приплюсовать "затраты" на создание сервера приложений. И, уже, в который раз, мне непонятна попытка "разгрузить" сервер СУБД сервером приложений?!

Единственно место, где я вижу необходимость среднего звена - это в системах с одновременным числом пользователей более, чем поддерживаемых сервером СУБД (32 768 для MS SQL). В таких системах без пуллинга коннектов на среднем звене необойтись.
...
Рейтинг: 0 / 0
12.10.2005, 13:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319882
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChЭто и так у меня отнимает кучу времени, чтобы приводить здесь еще начальный курс ООП.

Не надо нам читать начальный курс ООП. У нас с этим делом нет проблем! От Вас просили привести объектную модель, которую Вы у себя используете. Не более того. Но, раз у Вас "нет времени", то рабди бога...
...
Рейтинг: 0 / 0
12.10.2005, 13:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319890
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklin
Наличие DSQL - вот самая большая проблема.

Которая приводит к:
1. необходимости раздачи прав на таблицы (представления) = дыра в системе безопастности.
2. постоянная перекомпиляция хп, выполняющих это DSQL, что пагубно сказыватеся на производительности.

С пунктом 2 согласен, об этом я писал уже... Так уж существенно это производительность не подсаживает, зато дает гораздо большую гибкость в разработке. Это просто вопрос выбора приоритетов.
С пунктом 1 не согласен - здесь все зависит от настройки системы безопасности. К тому же при наличии сервера приложений можно вообще закрыть доступ пользователей системы к СУБД напрямую - соответственно безопасность для пользователя будет обеспечиваться логикой приложения, а не СУБД. Кстати, еще один плюс использования сервера приложений.
...
Рейтинг: 0 / 0
12.10.2005, 13:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319913
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinНе надо нам читать начальный курс ООП. У нас с этим делом нет проблем! От Вас просили привести объектную модель, которую Вы у себя используете. Не более того. Но, раз у Вас "нет времени", то ради бога...
Да боюсь что у некоторых проблемы как раз есть, судя по задаваемым вопросам. И что-то я не видел призывов привести здесь объектную модель, вопрос был вообще в том, зачем я использую объекты, все ведь прекрасно без них работает. Просто разговор совершенно неконструктивный, и я не думаю, что даже если я потрачу кучу времени и распишу здесь объектную модель, что-то изменится. Кстати, процитированная реплика была обращена не к Вам.
...
Рейтинг: 0 / 0
12.10.2005, 13:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319936
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklin MainFrameХуже того - три! Так как приходится и сервер приложений распрделять. НО с тремя серверами задача решается - достигается нужная производительность при нужном числе пользователей.

Зачем мне распределять сервер приложений, если я могу "умощнить" сервер СУБД для необходимой производительности?!

(позволю себе несколько риторических замечаний)
1) Как "умощнить" сервер СУБД - я знаю только один способ - кластер оракла - что Вы имели ввиду?
2) Если звезды зажигаются - значит это кому нибудь нужно -
если сервера приложений существуют (и еще как существуют) - то это необходимая и полезная вещь.
...
Рейтинг: 0 / 0
12.10.2005, 13:35
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319942
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
авторС пунктом 2 согласен, об этом я писал уже... Так уж существенно это производительность не подсаживает,

Как сказать... Как сказать...

VladiChС пунктом 1 не согласен - здесь все зависит от настройки системы безопасности. К тому же при наличии сервера приложений можно вообще закрыть доступ пользователей системы к СУБД напрямую - соответственно безопасность для пользователя будет обеспечиваться логикой приложения, а не СУБД. Кстати, еще один плюс использования сервера приложений.

Хм... Закрыть прямой доступ можно, не спорю, тем замым "закрыв" дыру в защите СУБД от использования DSQL. А вот дополнительные затраты на "безопасность для пользователя будет обеспечиваться логикой приложения" считаю не оправданными. Т.е. если это можно (нужно) сделать средствами СУБД, то зачем реализовывать этот функционал в среднем слое.
...
Рейтинг: 0 / 0
12.10.2005, 13:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319974
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinА вот дополнительные затраты на "безопасность для пользователя будет обеспечиваться логикой приложения" считаю не оправданными.
А какие собственно дополнительные затраты? Разве у вас безопасность строится сиключительно на уровне безопасности СУБД? У вас же как я понял есть свой уровень безопасности для документов на уровне приложения? Так какие там получаются тогда дополнительные затраты?

Насчет умощнения сервера СУБД что тут можно сказать - умощнение сервера СУБД стоит на порядок дороже, чем поставить дополнительный промежуточный сервер и фактически стоимость такого умощнения растет экспоненциально требованиям к производительности (не знаю ничего про оракловые кластеры, но думаю и там не все так радужно, т.к. все в результате упирается в производительность дисковой подсистемы, а полностью распараллелить обращения к дискам вряд ли получится, как ни кластеризуй).
С другой стороны, даже в случае многозвенной архитектуры база данных все равно останется узким местом, сколько ни ставь серверов приложений, я прекрасно понимаю, что это не панацея.
...
Рейтинг: 0 / 0
12.10.2005, 13:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33319990
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
VladiCh И что-то я не видел призывов привести здесь объектную модель, вопрос был вообще в том, зачем я использую объекты, все ведь прекрасно без них работает.
Правильно! Но если не понятен вопрос до сих пор, разжуем: Зачем вы используете объекты, которые преобразуете из таблиц, ХП и еще из чего-то в БД , вместо прямого обращения к БД через ХП?
Так понятнее?

авторПросто разговор совершенно неконструктивный, и я не думаю, что даже если я потрачу кучу времени и распишу здесь объектную модель, что-то изменится.
Конечно изменится! Мы наконец поймем, используете ли вы свою объектную модель для чего-то еще в приложении или только для того, чтобы вызвать один метод для разных унаследованных объектов с соответствующими параметрами . Ужас, если только второе, пытаюсь не верить - вот и прошу, чтобы показали. Жалко чтоли? Не надо всю модель расписывать, структуру работы и использования и особенно применения опишите.

авторКстати, процитированная реплика была обращена не к Вам.
К нам, к нам, мы это они :))

-- Tygra's --
...
Рейтинг: 0 / 0
12.10.2005, 13:50
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320033
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh pkarklinА вот дополнительные затраты на "безопасность для пользователя будет обеспечиваться логикой приложения" считаю не оправданными.
А какие собственно дополнительные затраты? Разве у вас безопасность строится сиключительно на уровне безопасности СУБД? У вас же как я понял есть свой уровень безопасности для документов на уровне приложения? Так какие там получаются тогда дополнительные затраты?

Нет, не на "уровне приложения", а именно на уровне "СУБД" из какого бы приложения не обратились к бд (хоть из QA). Пользователь не увидит докуенты, которые ему не положено видеть и не сможет менять документы, которые ему не положено менять!

VladiChНасчет умощнения сервера СУБД что тут можно сказать - умощнение сервера СУБД стоит на порядок дороже, чем поставить дополнительный промежуточный сервер и фактически стоимость такого умощнения растет экспоненциально требованиям к производительности

Абсолютно не согласен. Вы опять посчитали только малую толику затрат. Т.е. Вы не приплюсовали стоимость разработки третьего звена, которое можно было бы и не использовать.
...
Рейтинг: 0 / 0
12.10.2005, 14:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320042
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Я еще дальше пойду - напишу вкратце, как оно у нас, а вы уж покажите, в какое место нужно прикрутить ООП_чего-то_там.

Значит....
1. Список. Есть процедура TableNameLst, возможно с параметрами, которая приносит записи из таблицы. Форма с гридом, в котором колонки. Есть запрос exec TableNameLst, который в грид отдает результат. Все.
2. Единичная запись - просмотр, редактирование и т.д. ХП: TableNameGet @ID, приносит одну запись. На форме этот запрос, компоненты для просмотра и изменения данных полей записи. Все. Если есть связанные списки с этой записью из других таблиц - на закладках все они в виде списков.
3. Изменение единичной записи. Все на той же форме есть компонент с процедурами TableNameIns, TableNameUpd, которые вызываются исходя из того, добавили или меняли запись. Все.
4 и все остальное. Допустим хотим мы, чтобы для выбранной записи (в списке или при редактировании) чего-то произошло по нашему велению - кидаем на форму запрос типа exec TableNameDoSomething, передаем туда ID записи, параметры (если их задаем руками), исполняем. Все.

И? Куды тут ООП_механику_данных?

Еще раз замечу, чтобы не было отговорок: речь идет не об ООП вообще, а об вашей ООП_механике_данных_СУБД и только о ней.

-- Tygra's --
...
Рейтинг: 0 / 0
12.10.2005, 14:01
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320161
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinАбсолютно не согласен. Вы опять посчитали только малую толику затрат. Т.е. Вы не приплюсовали стоимость разработки третьего звена, которое можно было бы и не использовать.
Т.е. вы хотите сказать, что для всех пользователей, имеющих доступ к системе, заведены логины к СУБД и все работает на row level security? Таким образом можно построть только довольно простую систему безопасности с кучей ограничений. А как насчет полноценной role based security с редактируемым списком прав для каждого объекта и наследованием этих прав?возможностью разрешать/запрещать, в общем внешне это очень похоже на права на файлы a-la права в NTFS... Реализуете это средствами СУБД?

tygraЯ еще дальше пойду - напишу вкратце, как оно у нас, а вы уж покажите, в какое место нужно прикрутить ООП_чего-то_там.

Тут трудно сказать в какое место надо ООП прикрутить, скорее надо все выкинуть и написать с использованием ООП, по-другому не получится :)

Дяя создания новой редактируемой таблицы вам придется создать новую форму, написать процедуры для получения информации/изменения/удаления и т.п.
Я могу описать, как это делается у меня.
Есть форма ObjectList, которая отображает объекты любого типа с возможностью сортировки, поиска, постраничного пролистывания и т.п.
В ее конструктор передается параметр типа IObjectType - это те самые метаданные типа, которые кэшируются в сервере приложений.
При изменении, добавлении конкретного объекта на основании этих метаданных автоматически генерится формочка для редактирования/добавления объектов, если есть ссылки на другие объекты, то в зависимости от настроек могут быть разные варианты выбора - или через аткую же форму ObjectList, или через выпадающий список и т.п. На крайний случай можно для какого-нибудь типа переопределить форму выбора элемента.
При удалении объекта автоматически на основании опять же метаданных о связях между объектами вычищаются или не вычищаются всязанные с ним объекты.
В общем, при добавлении нового типа в системе у меня уже есть готовый механизм для редактирования данных объектов этого типа, назначения прав на объекты этого типа и т.п. Писать какой-то код для этого в общем случае не требуется.
Это как раз хороший пример повторного использования кода, который дает ООП в общем и моя реализация в частности.
...
Рейтинг: 0 / 0
12.10.2005, 14:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320176
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Насчет прав уточню - если речь идет о том, чтобы просто закрыть доступ ко всем таблицам и открыть только для хранимых процедур, в которые передавать всякие ID пользователя - такой вариант не катит. Это получается то же security на уровне приложения, только это приложение СУБД, а не промежуточного слоя. От моего варианта отличается только тем, что доступ к таблицам у вас закрывается на уровне СУБД, а у меня на уровне сервера приложений, других принципиальных отличий нет, так же как и нет отличий в трудоемкости реализации. Я не говорю про реализацию всего сервера приложений - он вообще-то не для этих целей создавался.
...
Рейтинг: 0 / 0
12.10.2005, 14:35
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320274
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
авторТ.е. вы хотите сказать, что для всех пользователей, имеющих доступ к системе, заведены логины к СУБД и все работает на row level security? Таким образом можно построть только довольно простую систему безопасности с кучей ограничений.

Логины заведены для всех. Система безопасности очень сложная.

авторА как насчет полноценной role based security с редактируемым списком прав для каждого объекта и наследованием этих прав?возможностью разрешать/запрещать, в общем внешне это очень похоже на права на файлы a-la права в NTFS... Реализуете это средствами СУБД?

Именно такая система и есть. Практическая полная копия ACL винды. На счет средств СУБД:
-Членство в роли бд - это средство СУБД?
-Проверка принадлежности текущго пользователя к роли - это средство СУБД?
-Связывание таблиц с данными с таблицами ACL - это средства СУБД?


авторНасчет прав уточню - если речь идет о том, чтобы просто закрыть доступ ко всем таблицам и открыть только для хранимых процедур, в которые передавать всякие ID пользователя - такой вариант не катит.

Никаких ID пользователей в хп не передаются.
...
Рейтинг: 0 / 0
12.10.2005, 15:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320279
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Ради интереса опишу как это делается у меня.

Для списка объектов у меня одна единственная форма на все приложение и если добавляются новые типы объектов, то с этой формой ничего делать не надо, тем более генерить что-то

Для редактирования/просмотра объекта нужно добавить форму, унаследованную от формы супертипа и поместить на нее контролы для доп. атрибутов. Для работы с доп. атрибутами создаются процедуры. Контролы с процедурами связываются и все. Процедуры тоже создаются автоматически.
Для простых типов даже форму добавлять не нужно.

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

Регистрация производится вызовом одной процедуры с минимум 2 параметрами
Класс и суперкласс
...
Рейтинг: 0 / 0
12.10.2005, 15:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320299
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shtock
Участник
Вот насчет "А как насчет полноценной role based security с редактируемым списком прав для каждого объекта и наследованием этих прав?возможностью разрешать/запрещать, в общем внешне это очень похоже на права на файлы a-la права в NTFS... Реализуете это средствами СУБД?" могу сказать точно - реализуется, так как проектировал это сам. Права на методы, свойства, отчеты, приложения, которые могут работать с БД (т.е. SQLNavigator не пройдет) и прочее прочее прочее.
...
Рейтинг: 0 / 0
12.10.2005, 15:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320377
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Ну хорошо, определенная часть системы security ложится на плечи СУБД, что ее немного упрощает. Но для меня например неприемлемым является невозможность использования Dynamic SQL в хранимых процедурах. У меня система security не завязана на security СУБД, но по возможностям аналогична.
...
Рейтинг: 0 / 0
12.10.2005, 15:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320436
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChНо для меня например неприемлемым является невозможность использования Dynamic SQL в хранимых процедурах.

Я все-таки использую динамический SQL, но только для работы с временными таблицами для построения cross-tab отчетов. ;)
...
Рейтинг: 0 / 0
12.10.2005, 15:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320620
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну вот, у всех почти одинаково.
Только у одних автоматически что-то генерится, а у кого-то вручную, но результат тот же - те же формы, те же процедуры.

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


VladiChЕсть форма ObjectList, которая отображает объекты любого типа с возможностью сортировки, поиска, постраничного пролистывания и т.п.
В ее конструктор передается параметр типа IObjectType - это те самые метаданные типа, которые кэшируются в сервере приложений.
При изменении, добавлении конкретного объекта на основании этих метаданных автоматически генерится формочка для редактирования/добавления объектов, если есть ссылки на другие объекты, то в зависимости от настроек могут быть разные варианты выбора - или через аткую же форму ObjectList, или через выпадающий список и т.п. На крайний случай можно для какого-нибудь типа переопределить форму выбора элемента.
Тут я только не понял - у вас форма на лету создается в процессе выполнения приложения или все же на стадии разработки?
Ну и форма ObjectList - она вроде как одна на всех. А фильтры? Динамически?

-----------

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

Когда ее пойму (когда время будет), смогу лучше рассказать, а пока что если только где в инете информация есть.

-- Tygra's --
...
Рейтинг: 0 / 0
12.10.2005, 16:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320702
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraТут я только не понял - у вас форма на лету создается в процессе выполнения приложения или все же на стадии разработки?
Ну и форма ObjectList - она вроде как одна на всех. А фильтры? Динамически?

Вы про форму редактирования? Да, форма в процессе выполнения приложения создается. Фильтры тоже создаются динамически.

tygraНу вот, у всех почти одинаково.
Только у одних автоматически что-то генерится, а у кого-то вручную, но результат тот же - те же формы, те же процедуры.

Ну так в этом и есть главное отличие - много писать кода или мало, проще поддерживать или сложнее. Все это ведь не ради каких-то метафизических премуществ создавалось или моды, а ради того, чтобы систему проще было расширять и поддерживать.
...
Рейтинг: 0 / 0
12.10.2005, 16:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320715
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraНо вообще, сейчас к нам вернулся старый товарищ на работу, он разработчик системы ВЕРО - единый реестр объектов. Вот там все автоматизировано на полную катушку - список объектов единый, от него наследуются почти все сущности, есть типы объектов, которые так-же могут наследоваться друг от друга и от них зависит много чего. Система мощная, на объект можно навесить все, что захочется - все это настраивается, так же может быть множество атрибутов (тоже настраивается), независимо от объекта есть универсальные методы, есть собственные, есть мощная система статусов, есть система прав - как общая, так и на конкретный объект - и вся она на базе СУБД.
Но все это делается средствами СУБД, клиент как всегда только отображает и кое-что универсализирует в смысле интерфейса

Ну собственно моя система сильно похожа на то, что вы описали, и довольно много работы в ней также делается в СУБД. Список объектов единый, от него наследуются все сущности, ну и все остальное тоже. Я думаю у Old Nick все по аналогичным принципам построено. Единственно - наследование бизнес-логики делать на уровне СУБД - на эту тему я уже высказывался - это на мой взгляд ненужное извращение.
...
Рейтинг: 0 / 0
12.10.2005, 16:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33320950
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну тут видите - взгляды наши не совпадают

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

-- Tygra's --
...
Рейтинг: 0 / 0
12.10.2005, 18:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321176
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
Значит....
автор1. Список. Есть процедура TableNameLst, возможно с параметрами, которая приносит записи из таблицы. Форма с гридом, в котором колонки. Есть запрос exec TableNameLst, который в грид отдает результат. Все.
2. Единичная запись - просмотр, редактирование и т.д. ХП: TableNameGet @ID, приносит одну запись. На форме этот запрос, компоненты для просмотра и изменения данных полей записи. Все. Если есть связанные списки с этой записью из других таблиц - на закладках все они в виде списков.
3. Изменение единичной записи. Все на той же форме есть компонент с процедурами TableNameIns, TableNameUpd, которые вызываются исходя из того, добавили или меняли запись. Все.
4 и все остальное. Допустим хотим мы, чтобы для выбранной записи (в списке или при редактировании) чего-то произошло по нашему велению - кидаем на форму запрос типа exec TableNameDoSomething, передаем туда ID записи, параметры (если их задаем руками), исполняем. Все.

И? Куды тут ООП_механику_данных?

Еще раз замечу, чтобы не было отговорок: речь идет не об ООП вообще, а об вашей ООП_механике_данных_СУБД и только о ней.

Если в вашей системе завести 3 документа (накладная, заявление об увольнении, прием на работу) - то это будет 3 разных таблицы (как и у других). Теперь для того, чтобы реализовать операцию "Подпись" вы создадите 3 ХП Table1SignDoc/Table2SignDoc/Table3SignDoc и в каждой напишите приблизительно один и тот же код с точностью до имени таблицы.
Нужно будет доавить вторую подпись - на море по колено - продублируем
все ХП еще один раз.

Тогда как в ОО вы ОДИН раз напишите логику подписи документа и будете вызывать везде ОДИН базовый метод для ВСЕХ документов системы.

Вообще, непонятна ваша логика - на GUI ООП это круто, а для БЛ логики нет. Почему? Чем вдруг формы, контролы и работа с ними сильно отличаются от документов, клиентов и т.п.??? Такие же объекты, у которых функциональность пересекается из-зи чего удобно использовать наследование и полиморфизм при работе с ними.
...
Рейтинг: 0 / 0
12.10.2005, 19:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321205
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
2tygra:
Еще представьте, что Borland написал бы VCL по вашим правилам - на каждый контрол
ControlNameSetSize
ControlNameGetSize
ControlNameSetWith
ControlNameGetWidth
и т.п.
Для каждого нового пришлось бы написать ручками все методы. Ваше решение - полный аналог.
...
Рейтинг: 0 / 0
12.10.2005, 20:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321393
Mainframe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mainframe
Участник
Terrorist Есть текст для, например, вопроса. Что с ним сделать для отображения нужно, что бы он был готов? Пожарить? :)
Долго писать, но можете, если интересно, прочитать стандрат IMS QTI на
imsorg .
...
Рейтинг: 0 / 0
13.10.2005, 02:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321712
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
ООПЕсли в вашей системе завести 3 документа (накладная, заявление об увольнении, прием на работу) - то это будет 3 разных таблицы (как и у других). Теперь для того, чтобы реализовать операцию "Подпись" вы создадите 3 ХП Table1SignDoc/Table2SignDoc/Table3SignDoc и в каждой напишите приблизительно один и тот же код с точностью до имени таблицы.
Нужно будет доавить вторую подпись - на море по колено - продублируем
все ХП еще один раз.

Вообще-то, можно и не так.
Если механизм "подписывания в базе" для записей разных таблиц одинаков, то я создам одну процедуру и "имя таблицы" передам в нее параметром.
...
Рейтинг: 0 / 0
13.10.2005, 10:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321720
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
А еще есть понятие "генерация SQL скриптов по шаблону". Так что никто ничего по 100 раз в коде не дублирует, пишем однотипный шаблон, по нему собираются нужные скрипты, процедуры, триггеры и прочее.
...
Рейтинг: 0 / 0
13.10.2005, 10:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321788
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 ООП

Да вам, товарищ, на sql да и вообще с СУБД научиться работать бы надо - хотя бы вообще работать, а потом уж хорошо работать. А вот потом уже можно начинать комментировать - тогда не получится тот бред, который вы тут написали.

Если разработчик не идиот, то он создаст одну базовую таблицу - документ, от которой наследуются остальные - заявления, накладные и т.п. И подпись будет ставиться на базовом документе - потому дергать будет разработчик_не_идиот одну процедуру SignDocument.
Для воторой подписи соответственно создадим поле в базовой таблице и т.д. (см. выше)

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

Твою маман....

-- Tygra's --
...
Рейтинг: 0 / 0
13.10.2005, 10:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321814
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
С интересом прочитал всю тему.

Предалагю все же разделять два вопроса:
а) создание многозвенных приложений
б) вынос бизнес-логики за СУБД (в моем понимании, именно для этого и создается сервер приложений)

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

Что касается сервера приложений, то тут пока я видел только два примера, для которых такой подход м.б. применим:
- работа с геторогенными БД (создание СП м.б. эффективней некой консолидации)
- ограничение на макс. кол-во пользователей (хотя это не совсем укладывается в вынос БЛ) Тут, скорее всего, речь будет идти о неправильно выбранной СУБД для данной задачи.

Еще могу себе представить вынесение "оберток" в некий промежуточный слой - упрощается создание разнородных клиентских приложений к одной БД. Но опять же, это не является необходимостью выноса БЛ за пределы БД.
...
Рейтинг: 0 / 0
13.10.2005, 10:38
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321825
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
ограничение на макс. кол-во пользователей (хотя это не совсем укладывается в вынос БЛ) Тут, скорее всего, речь будет идти о неправильно выбранной СУБД для данной задачи.

если таки подумать :D, то БЛ опять же остается в БД. И это вырождается в вариант "толстого драйвера"
...
Рейтинг: 0 / 0
13.10.2005, 10:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33321964
ООП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ООП
Гость
2tygra:
авторЕсли разработчик не идиот, то он создаст одну базовую таблицу - документ, от которой наследуются остальные - заявления, накладные и т.п. И подпись будет ставиться на базовом документе - потому дергать будет разработчик_не_идиот одну процедуру SignDocument.
Для воторой подписи соответственно создадим поле в базовой таблице и т.д. (см. выше)

Гениально! На каждый уровень иерархии объектов системы мы создадим по таблице.
У нас будет 1 таблица с ИД и номером, потом таблица с подписями, еще одна для базовых документов с контрагентами и т.п. При выборке одного документа мы будем делать JOIN из N таблиц. А базовая у нас будет содержать миллионы записей и любой запрос по любому документу будет обязательно шариться по ней. И это все для того, чтобы доказать, что ООП на сервере не нужен.
Прогрессивный подход к построению КС систем.

2 ACRUS и Инженер:
То, что вы предлагаете и есть один из вариантов надстройки над СУБД. Просто у вас она реализована средствами самой СУБД. Д.Сорокин приводил пример аналогичной надстройки, выполненной на .Net. В случае .Net большую часть того, что вам приходится писать самим - а именно хранение иерархии таблиц, выбор нужной таблицы для выборки (полиморфизм) и т.п. вы получаете "бесплатно" за счет использования ОО языка. Собственно, про это я и говорю.
...
Рейтинг: 0 / 0
13.10.2005, 11:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33322075
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
ООПГениально! На каждый уровень иерархии объектов системы мы создадим по таблице.
У нас будет 1 таблица с ИД и номером, потом таблица с подписями, еще одна для базовых документов с контрагентами и т.п. При выборке одного документа мы будем делать JOIN из N таблиц
Вы правда идиот или просто прикидываетесь?

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

авторА базовая у нас будет содержать миллионы записей и любой запрос по любому документу будет обязательно шариться по ней.
А вот это правда - так обычно и делают, если используют именно такую архитектуру. Так работает система ВЕРО, причем в нескольких крупных предприятиях с огромным количеством данных - и работает хорошо. Просто нужно руки прямые иметь и знать, чего делаешь, но вам этого не понять :)

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

авторПрогрессивный подход к построению КС систем.
Конечно. У вас то его вообще нет - подхода, до сих пор все на клиенте делаете. Хотя может и вообще ничего не делаете - судя по постам. Может вы просто дворником в ИТ конторе работаете? Слышите иногда разговоры программеров - вот и нахватались "знаний"

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

-- Tygra's --
...
Рейтинг: 0 / 0
13.10.2005, 11:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33322548
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
ООП2tygra:
У нас будет 1 таблица с ИД и номером, потом таблица с подписями, еще одна для базовых документов с контрагентами и т.п. При выборке одного документа мы будем делать JOIN из N таблиц. А базовая у нас будет содержать миллионы записей и любой запрос по любому документу будет обязательно шариться по ней[/quote]
Даже в таком :) варианте, при условии грамотных индексов и запросов работать будет быстро. Я бы даже рискнул сказать ОЧЕНЬ быстро :)


[quot]
То, что вы предлагаете и есть один из вариантов надстройки над СУБД. Просто у вас она реализована средствами самой СУБД. Д.Сорокин приводил пример аналогичной надстройки, выполненной на .Net. В случае .Net большую часть того, что вам приходится писать самим - а именно хранение иерархии таблиц, выбор нужной таблицы для выборки (полиморфизм) и т.п. вы получаете "бесплатно" за счет использования ОО языка. Собственно, про это я и говорю.

Я еще раз предлагаю разделять использование "обертки" и использование СП с вынесенной в него БЛ.
При определенных обстоятельствах я "ЗА" обертки. Но использование СП для меня пока остается загадкой.
...
Рейтинг: 0 / 0
13.10.2005, 13:35
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33322555
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
ООПУ нас будет 1 таблица с ИД и номером, потом таблица с подписями, еще одна для базовых документов с контрагентами и т.п. При выборке одного документа мы будем делать JOIN из N таблиц. А базовая у нас будет содержать миллионы записей и любой запрос по любому документу будет обязательно шариться по ней
Даже в таком :) варианте, при условии грамотных индексов и запросов работать будет быстро. Я бы даже рискнул сказать ОЧЕНЬ быстро :)

То, что вы предлагаете и есть один из вариантов надстройки над СУБД. Просто у вас она реализована средствами самой СУБД. Д.Сорокин приводил пример аналогичной надстройки, выполненной на .Net. В случае .Net большую часть того, что вам приходится писать самим - а именно хранение иерархии таблиц, выбор нужной таблицы для выборки (полиморфизм) и т.п. вы получаете "бесплатно" за счет использования ОО языка. Собственно, про это я и говорю.
Я еще раз предлагаю разделять использование "обертки" и использование СП с вынесенной в него БЛ.
При определенных обстоятельствах я "ЗА" обертки. Но использование СП для меня пока остается загадкой.
...
Рейтинг: 0 / 0
13.10.2005, 13:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33322695
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
авторУ нас будет 1 таблица с ИД и номером, потом таблица с подписями, еще одна для базовых документов с контрагентами и т.п. При выборке одного документа мы будем делать JOIN из N таблиц. А базовая у нас будет содержать миллионы записей и любой запрос по любому документу будет обязательно шариться по ней

Да. Именно так и должно быть.
Представьте, как в системе с отдельными таблицами для каждого документа, сделать такую операцию: "удалить все документы подписанные мистером ВВП"
Придеться, сканировать N таблиц и чётко знать сколько таких таблиц есть и генерить динамический СКЛ!

В случае одной базовой таблицы, для общих свойств всех документов, выполняется один СКЛ оператор, все связанные таблицы могут удалить записи ссылающиеся на базовые автоматически. И при этом совершенно не важно сколько у нас типов разных документов и где еще хранятся их атрибуты.
...
Рейтинг: 0 / 0
13.10.2005, 14:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323276
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Да, ООП, здесь вы действительно что-то не то написали....
Более-менее нормальные объектные архитектуры используют действительно единую идентификацию всех объектов через одну общую таблицу. И это работает достаточно быстро даже в случае миллионов записей.
Про использование СП я уже писал. Если говорить про бизнес-логику, то на него можно выносить часть бизнес-логики, не работающую с множествами, можно выносить специфические алгоритмы, плохо реализуемые средствами SQL, он может выполнять много вспомогательных функций - как то авторизация, кэширование, шифрование и т.п., с его помощью легче построить приложение, независимое от конкретной СУБД. Это все необязательно в общем случае, просто в зависимости от требований к приложению может быть целесообразно. Вообще говоря, при удаленной работе с БД (не из локальной сети) я почти всегда за использование промежуточного слоя, даже если он и не выполняет тех функций СП, которые я описал и является "драйвером" в термнологии tygra - просто это обеспечивает большую защищенность СУБД. С моей точки зрения, корпоративная СУБД наружу должна быть закрыта полностью.
...
Рейтинг: 0 / 0
13.10.2005, 16:47
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323318
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Если говорить про объектную архитектуру бизнес-логики (это не равно полному выносу бизнес-логики на сервер приложений), то тут я уже кучу аргументов приводил, и не услышал ни одного внятного аргумента против кроме "зачем это делать, у нас и так все работает". Ну еще был аргумент, что это усложнит систему. Но я сним не согласен, т.к. мою систему это нисколько не усложняет, а наоборот делает более простой для понимания, расширения и поддержки.
...
Рейтинг: 0 / 0
13.10.2005, 16:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323360
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
авторЕсли говорить про объектную архитектуру бизнес-логики (это не равно полному выносу бизнес-логики на сервер приложений), то тут я уже кучу аргументов приводил, и не услышал ни одного внятного аргумента против кроме "зачем это делать, у нас и так все работает".

Не слышать, и не хотеть слышать 2 большие разницы. Зачем мне объектная модель БЛ, если я ее реализую в реляционной СУБД?! Вот скажите, зачем?! Какие я получу от этого приемущества?
...
Рейтинг: 0 / 0
13.10.2005, 17:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323395
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VladiChЕсли говорить про объектную архитектуру бизнес-логики (это не равно полному выносу бизнес-логики на сервер приложений)
Т.Е. Вы предлагаете использовать бизнес-логику на ООП в СУБД
Пример: MS SQL с .Net или Oracle с Java.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
13.10.2005, 17:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323398
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinНе слышать, и не хотеть слышать 2 большие разницы. Зачем мне объектная модель БЛ, если я ее реализую в реляционной СУБД?! Вот скажите, зачем?! Какие я получу от этого приемущества?
Вот-вот. То что вы мне говорите, это еще один вариант на тему "зачем это делать, у нас и так все работает". Так что кто не хочет слышать - это большой вопрос. То, что у вас это реализуется в реляционной СУБД - это я понял. Но реляционная - то она реляционная, а язык - процедурный a-la Pascal, Basic и т.п. Я не говорю здесь про чистые SQL-возможности, я говорю про расширения SQL для написания хранимых процедур. Чем плох этот язык по сравнению с ОО-языком - еще раз написать? Попробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете. Поддерживать и расширять такой код гораздо менее удобно, примеры я уже приводил выше. Структурировав все приложение по ОО-принципам от этой проблемы я избавляюсь. Процедурный SQL у меня работает на самом нижнем уровне, выполняя роль своеобразного ассемблера для более высокоуровневого языка. Давайте только не вдаваться еще в дискуссии, что тут более высокоуровневое, я не имел в виду низкоуровневость SQL самого по себе, а всего лишь его место в моей системе.
Это я уже повторяюсь. Больше повторяться не буду - надоело. Если хотите - пролистайте топик на несколько страниц назад, посмотрите мои аргументы, примеры, вопросы и т.п.
...
Рейтинг: 0 / 0
13.10.2005, 17:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323427
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
VoDAТ.Е. Вы предлагаете использовать бизнес-логику на ООП в СУБД
Пример: MS SQL с .Net или Oracle с Java.
Да нет же... Бизнес-логика же все равно полностью не выносится на сервер приложений, какая-то ее часть работает в СУБД.
Просто здесь люди, когда видят аргументы в пользу сервера приложений сразу себе представляют, что я на сервере приложений делаю выборку из таблицы, пробегаю по ней и для каждой записи например делаю другую выборку или insert... Ну или что-то в этом роде. Специально для них я написал, что логика, которая работает со множествами так и будет с ними работать в СУБД. Просто я ввожу более высокоуровневые абстракции, чем вызовы хранимых процедур - вот и все. И код, реалзующий эти абстракции работает на сервере приложений, хотя в принципе может работать и на клиенте, это на самом деле не так принципиально. г-н Инженер здесь правильно высказался, что мы обсуждаем 2 разных вопроса - о применимости сервера приложений и об объектной архитектуре бизнес-логики. И мешать их в кучу не совсем правильно.
...
Рейтинг: 0 / 0
13.10.2005, 17:30
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323505
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChТо что вы мне говорите, это еще один вариант на тему "зачем это делать, у нас и так все работает". Так что кто не хочет слышать - это большой вопрос. То, что у вас это реализуется в реляционной СУБД - это я понял. Но реляционная - то она реляционная, а язык - процедурный a-la Pascal, Basic и т.п.
...
Если хотите - пролистайте топик на несколько страниц назад, посмотрите мои аргументы, примеры, вопросы и т.п.

Так я и не пытаюсь на процедурном языке реализовывать наследование, инкапсуляцию и полиморфизм, ибо действительно это будет криво. А вот возможностей TSQL для обработки реаляционных данных более чем достаточно для наибыстрейшей обработки правильно спроектированной структуры данных . Топик я читал, особенно вспоминаются аргументы про "1500 хранимых процедур" (кстати у меня их в разы больше, а современные ERP системы содержат их 10 и 100 тысяч. Т.е. все их разработчики лохи и не тут траву курили, когда систему разрабатывали?), и про то, что почему то надо "почти все" перелапачивать (почему все, опять непонятно). И Вам так же уже в этом топике отвечали на ваши вопросы. И в пплане невозможности сопровождения таких систем (без ООП) и т.п.

авторПросто здесь люди, когда видят аргументы в пользу сервера приложений сразу себе представляют, что я на сервере приложений делаю выборку из таблицы, пробегаю по ней и для каждой записи например делаю другую выборку или insert... Ну или что-то в этом роде. Специально для них я написал, что логика, которая работает со множествами так и будет с ними работать в СУБД. Просто я ввожу более высокоуровневые абстракции, чем вызовы хранимых процедур - вот и все.

Вы дадите гарантию, что Ваши "высокоуровневые абстракции" генерят оптимальный код и структуру с точки зрения реляционной бд? Что очень Важно для OLTP систем, когда каждый запрос и используемые им объекты приходится вылизывать, дабы добиться максимального быстродействия. У меня есть сомнения. Можете их опровергнуть? Что автоматически создаеются нужные индексы, что динамически генерируемые запросы оптимизированы? Ведь порой изменения порядка объединения таблиц или условий отбора в запросе катастрофически влияет на план его выполнения.
...
Рейтинг: 0 / 0
13.10.2005, 17:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323517
VoDA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VoDA
Участник
VladiChо применимости сервера приложений и об объектной архитектуре бизнес-логики. И мешать их в кучу не совсем правильно.Предлагаю повторно поднять вопрос о том, когда лучше, а когде - нет применять сервер приложений.

----

SAnalis.ru - Just for fun. Еще расту, а так я ДЖИП!
...
Рейтинг: 0 / 0
13.10.2005, 17:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323525
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChчто мы обсуждаем 2 разных вопроса - о применимости сервера приложений и об объектной архитектуре бизнес-логики. И мешать их в кучу не совсем правильно.

нет уж, позвольте. Это Вы обосновывает применение ООП на сервере приложение "процедурностью" TSQL. Так что все здесь взаимосвязано...
...
Рейтинг: 0 / 0
13.10.2005, 17:59
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323583
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Вопрос для всех противников объектного слоя.
Как вы думаете, для чего существуют ORM-средства и кто ими пользуется?
Для тех кто не знает что это такое

pkarklinА вот возможностей TSQL для обработки реаляционных данных более чем достаточно для наибыстрейшей обработки правильно спроектированной структуры данных
Для обработки данных достаточно. Обработка данных и у меня в конечном итоге производится на TSQL. Но ведь бизнес-логика и обработка данных - это не совсем одно и то же, не правда ли? Бизнес-логика связана с определенными объектами реального мира, между которыми существуют определенные отношения. И моделировать всю эту систему в целом только посредством TSQL довольно неудобно.

pkarklinВы дадите гарантию, что Ваши "высокоуровневые абстракции" генерят оптимальный код и структуру с точки зрения реляционной бд? Что очень Важно для OLTP систем, когда каждый запрос и используемые им объекты приходится вылизывать, дабы добиться максимального быстродействия. У меня есть сомнения. Можете их опровергнуть? Что автоматически создаеются нужные индексы, что динамически генерируемые запросы оптимизированы? Ведь порой изменения порядка объединения таблиц или условий отбора в запросе катастрофически влияет на план его выполнения.
Что вы называете оптимальным кодом и структурой? А вы дадите гарантию, что вы генерите такой код и структуру вручную? А доказать можете?
А кто-нибудь вообще может дать такую гарантию? Какие-то странные вопросы вы задаете.
Да, я считаю, что код генерится достаточно оптимальный для моей задачи. Вручную его можно конечно оптимизировать лучше, но возможности для ручной оптимизации в системе есть. А там, где такая оптимизация не нужна, я могу кучу времени сэкономить на разработке и поддержке.

pkarklinнет уж, позвольте. Это Вы обосновывает применение ООП на сервере приложение "процедурностью" TSQL. Так что все здесь взаимосвязано...
Нет уж позвольте. Я обосновываю применение ООП процедурностью TSQL. Применение сервера приложений я обосновывал другими аргументами, и в принципе согласен что для многих задач сервер приложений не нужен. В моей системе он нужен в том числе и для более эффективного функционирования именно ООП-подсистемы, поэтому определенная связь есть, но не более того.
Сейчас я говорю именно об объектной прослойке, полезность которой на уровне бизнес-логики вы почему-то оспариваете.
О сервере приложений можно поговорить отдельно, я писал тоже уже несколько раз для каких целей он используется в моей системе.
...
Рейтинг: 0 / 0
13.10.2005, 18:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323615
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinТопик я читал, особенно вспоминаются аргументы про "1500 хранимых процедур" (кстати у меня их в разы больше, а современные ERP системы содержат их 10 и 100 тысяч. Т.е. все их разработчики лохи и не тут траву курили, когда систему разрабатывали?),
Да, назовите мне хотя бы парочку "современных ERP-систем", в которых не использовалась бы объектная бизнес-логика и сервер приложений. Желательно по-отдельности - в которых не используется одно и в которых не используется другое.
...
Рейтинг: 0 / 0
13.10.2005, 18:28
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323643
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
автор
Да, я считаю, что код генерится достаточно оптимальный для моей задачи. Вручную его можно конечно оптимизировать лучше, но возможности для ручной оптимизации в системе есть. А там, где такая оптимизация не нужна, я могу кучу времени сэкономить на разработке и поддержке.
В том то и дело, что более менее приемлимый код генериться, только для очень простых задач. И оправдано такое использование, только при создании приложений не зависящих от СУБД.
Как только вы начинаете руками там что-то оптимизировать, сразу получаете зависимость от СУБД.
Других причин когда, то что можно сделать на СКЛ, делаеться, через ОРМ, я не вижу. Покажете?
...
Рейтинг: 0 / 0
13.10.2005, 18:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323660
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
TerroristВ том то и дело, что более менее приемлимый код генериться, только для очень простых задач. И оправдано такое использование, только при создании приложений не зависящих от СУБД. Как только вы начинаете руками там что-то оптимизировать, сразу получаете зависимость от СУБД.
Других причин когда, то что можно сделать на СКЛ, делаеться, через ОРМ, я не вижу. Покажете?
Не согласен ни с тем, что такой подход годится только для очень простых задач, ни с тем, что при оптимизации я получаю зависимость от СУБД. При оптимизации не изменяется интерфейс между объектным ядром и клиентом, вся оптимизация проводится внутри СУБД. Откуда тогда зависимость от СУБД?
Насчет того что других причин не видите - ну вы не одиноки в этом. Причины я уже наверное раз 10 описывал...
...
Рейтинг: 0 / 0
13.10.2005, 18:53
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323668
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
VladiChПри оптимизации не изменяется интерфейс между объектным ядром и клиентом, вся оптимизация проводится внутри СУБД.
А вот с этого места поподробнее - как именно для каждой из СУБД производится оптимизация ? Возьмем для примера любой из блокировочников MSSQL/DB2/ASA/ASE и что то еще версионное Oracle/FB/PostgreSQL (любую на выбор). Очень интересует вопросы, как Вы добьетесь независимости в логике транзакций, проектировании системы и оптимизации скорости между 2-мя выбранными из списков СУБД.
...
Рейтинг: 0 / 0
13.10.2005, 18:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323674
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Да, тут я может быть несколько некорректно высказался...
В этом случае действительно оптимизация будет зависимой от СУБД, но не сама система. Для каждой СУБД код придется оптимизировать отдельно (если это требуется). Если не требуется, то пользоваться стандартными возможностями.
...
Рейтинг: 0 / 0
13.10.2005, 19:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323724
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChВопрос для всех противников объектного слоя.
Как вы думаете, для чего существуют ORM-средства и кто ими пользуется?
Для тех кто не знает что это такое
Имхо все это реинкарнация идей про RAD. Вот я набросал мышкой метаданные(описал хмл-файлом, импортировал из розы итп)-и вот вам готовое приложение.
Для определенного класса задач это приемлемый подход.
Иногда довольно серьезные приложения пишутся на Ацессе с линкованными таблицами.
Никогда не сталкивались? :) Вот ОРМы, что-то в этом роде. До определенного уровня вполне приемлемо. Но только до него.

Да, кстати ОРМы очень уязвимы к устареванию технологий и политике поставщика\настроению гениального программиста. Так, что если вам нужно не слишком сложное, малонагруженное приложение сроком службы 2-3 года, то вам с ними по пути.


VladiChЧто вы называете оптимальным кодом и структурой? А вы дадите гарантию, что вы генерите такой код и структуру вручную? А доказать можете?
А кто-нибудь вообще может дать такую гарантию? Какие-то странные вопросы вы задаете.
Да, я считаю, что код генерится достаточно оптимальный для моей задачи. Вручную его можно конечно оптимизировать лучше, но возможности для ручной оптимизации в системе есть. А там, где такая оптимизация не нужна, я могу кучу времени сэкономить на разработке и поддержке.
Вы можете дать гарантию, что когда вам потребуется форсировать джойн-ордер или использование какого-нибудь индекса для конкретного тяжелого списка это:
а) будет вообще возможно
б) не затронет места, которые затрагивать не должно.
Вы можете дать подобные гарантии для случаев, когда запрос нужно переписать кардинально - с использованием юнионов или временных таблиц?
А для случаев, когда необходимо явное управлению уровнем изоляции\блокировками запросов?
Только не говорите, что вашему приложению это не грозит. Это много скажет о вашем приложении :)


VladiCh
Да нет же... Бизнес-логика же все равно полностью не выносится на сервер приложений, какая-то ее часть работает в СУБД.
Просто здесь люди, когда видят аргументы в пользу сервера приложений сразу себе представляют, что я на сервере приложений делаю выборку из таблицы, пробегаю по ней и для каждой записи например делаю другую выборку или insert... Ну или что-то в этом роде. Специально для них я написал, что логика, которая работает со множествами так и будет с ними работать в СУБД. Просто я ввожу более высокоуровневые абстракции, чем вызовы хранимых процедур - вот и все. И код, реалзующий эти абстракции работает на сервере приложений, хотя в принципе может работать и на клиенте, это на самом деле не так принципиально.
Т.е. вы начитываете "тяжелый список" из СУБД обычным sql-запросом, а потом на СП придумываете для этого списка какой-нибудь класс в вашей объектной модели?
Думаю у вас, по меньшей мере, большая объектная модель. Или я ошибаюсь?

VladiChПопробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете.
Ну за паскаль не скажу... Си подойдет?
Виндовз. Если у вас аллергия на виндоз - Юникс. :)
...
Рейтинг: 0 / 0
13.10.2005, 19:37
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323767
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
DrKonitoИмхо все это реинкарнация идей про RAD. Вот я набросал мышкой метаданные(описал хмл-файлом, импортировал из розы итп)-и вот вам готовое приложение.

ORM к RAD не имеет абсолютно никакого отношения.

DrKonitoДа, кстати ОРМы очень уязвимы к устареванию технологий и политике поставщика\настроению гениального программиста. Так, что если вам нужно не слишком сложное, малонагруженное приложение сроком службы 2-3 года, то вам с ними по пути.
Зависит от конкретного ORM. В общем случае согласен. Но я не использую сторонний ORM, мне своего достаточно.

DrKonito
Вы можете дать гарантию, что когда вам потребуется форсировать джойн-ордер или использование какого-нибудь индекса для конкретного тяжелого списка это:
а) будет вообще возможно
б) не затронет места, которые затрагивать не должно.
Вы можете дать подобные гарантии для случаев, когда запрос нужно переписать кардинально - с использованием юнионов или временных таблиц?

а) могу дать гаранитю
б) на 100% не уверен, но процентов так на 90 тоже могу дать гарантию
для случаев с использованием юнионов и временных таблиц да и для всех других случаев - я могу в качестве таблицы использовать view с триггерами на вставку/обновление/удаление, а также табличные функции и хранимые процедуры. я также могу сам запрос на выборку списка написать с нуля и сохранить в таблице типов. там все равно хранятся полуразобранные запросы на выборку с целью кэшированя, чтобы не собирать их каждый раз заново.

DrKonito
Т.е. вы начитываете "тяжелый список" из СУБД обычным sql-запросом, а потом на СП придумываете для этого списка какой-нибудь класс в вашей объектной модели?
Думаю у вас, по меньшей мере, большая объектная модель. Или я ошибаюсь?

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

DrKonito
VladiChПопробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете.
Ну за паскаль не скажу... Си подойдет?
Виндовз. Если у вас аллергия на виндоз - Юникс. :)
Ну давайте еще PL/1 и OS/360 вспомним... Конечно на этих языках писался большой софт. И сколько человек было в этих проектах задействовано?
...
Рейтинг: 0 / 0
13.10.2005, 20:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323822
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiChORM к RAD не имеет абсолютно никакого отношения.Я в курсе. Просто имхо это чем-то родственные идеи.
VladiCh DrKonitoДа, кстати ОРМы очень уязвимы к устареванию технологий и политике поставщика\настроению гениального программиста. Так, что если вам нужно не слишком сложное, малонагруженное приложение сроком службы 2-3 года, то вам с ними по пути.
Зависит от конкретного ORM. В общем случае согласен. Но я не использую сторонний ORM, мне своего достаточно.Тогда в роли гениального программиста выступаете вы и ваши коллеги и преемники зависят от вас. И еще, им тоже хочется написать _свой_ крутой суперпроизводительный обжект-релэшонал маппер ;).

VladiCh DrKonitoТ.е. вы начитываете "тяжелый список" из СУБД обычным sql-запросом, а потом на СП придумываете для этого списка какой-нибудь класс в вашей объектной модели?
Думаю у вас, по меньшей мере, большая объектная модель. Или я ошибаюсь?
Поясните, что вы понимаете под списками вообще и "тяжелыми списками" в частности.
Объектная модель пока небольшая - порядка сотни классов (я говорю разумеется только про те, которые описаны в БД).
Список=резалтсет, рекордсет, набор записей, датасет (выберите что вам ближе)
Под "тяжелым списком" я имею в виду запросы возвращающие сотни-тысячи-десятки тыщ записей, которые имеют достаточно сложную логику и медленно выполняются даже на чистом SQL.
VladiCh
DrKonito
VladiChПопробуйте например построить сложное приложение на чистом Pascal без использования ОО-расширений - поймете.
Ну за паскаль не скажу... Си подойдет?
Виндовз. Если у вас аллергия на виндоз - Юникс. :)
Ну давайте еще PL/1 и OS/360 вспомним... Конечно на этих языках писался большой софт. И сколько человек было в этих проектах задействовано?
Помню, когда ООП была новой темой были модны опыты на чем быстрее писать на Си или ЦПП. Группа программистов написал растровый редактор на Си, а потом переписала его на ЦПП.
Никакой разницы в скорости разработки выявлено не было :) Ссылку сейчас дать затруднительно - это год 1995 кажется был, журнал то-ли МирПК, толи еще что-то в этом духе.
Скажете-такие программисты :) А программисты они везде примерно одинаковые, а в ай-ти отделах особенно :)
А вы Брукса читали про то что нет "серебрянных пуль"? Или может хотя бы Джоела Спольски (который ДжоелОнСофтваре)? Имхо скорость разработки зависит от людей и задачи и меньше всего от инструмента. Если не брать конечно крайности.
...
Рейтинг: 0 / 0
13.10.2005, 21:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33323866
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Всем защитникам обязательной объектной ориентированности.

Имхо чтобы необходимость технологии представляющей новый уровень абстракции над "процедурным SQL", действительно была несомненна, а не приводила к пустому флэйму на форумах, она действительно должна означать повышение производительности труда, как минимум на порядок, по сравнению с "покрываемой" им низкоуровневой технологией
Как Си над асм-ом, как SQL над самостоятельным оперированием хэш-джойнами, как VB над Си в области интерфейса.
Не меньше. Иначе будут невразумительные заявления "А мне так удобнее - все заткнитесь". "А это сам Фаулер сказал - как вы не знаете кто такой Фаулер?". "А у Буча так написано - Всем читать Буча три раза".

И еще это должна быть зрелая технология. Не самопальная вечно недописанная обертка, не очередная продукция отдела маркетинга БольшойФирмы, а технология у которой есть хотя-бы десятилетняя перспектива.

Сами судите относятся ли ОРМы и самопальные апп-сервера к таким технологиям.
...
Рейтинг: 0 / 0
13.10.2005, 22:24
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324061
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklinТопик я читал, особенно вспоминаются аргументы про "1500 хранимых процедур" (кстати у меня их в разы больше, а современные ERP системы содержат их 10 и 100 тысяч. Т.е. все их разработчики лохи и не тут траву курили, когда систему разрабатывали?),
Ответе всетаки простому труженику:
как можно сопровождать систему из 100 тысяч ХП - без ОБЪЕКТНОГО (читай - иерархического) описания ? (причем желательно, чтобы происходила автоматическая синхронизация описания со всеми изменениями в базе)

Как вообще описывается столь сложная система - чтобы ЛЮБОЙ - с первого чтения мог понять : что где лежит и где найти то, что мне надо? (уж не говоря про перестройку логики работы)
...
Рейтинг: 0 / 0
14.10.2005, 08:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324092
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ПользовательОтвете всетаки простому труженику:
как можно сопровождать систему из 100 тысяч ХП - без ОБЪЕКТНОГО (читай - иерархического) описания ? (причем желательно, чтобы происходила автоматическая синхронизация описания со всеми изменениями в базе)

Можно. И такие системы сопровождаются, и без всякой объектной модели, хотя с некоторыми дополнительными наворотами, типа Workflow.

ПользовательКак вообще описывается столь сложная система - чтобы ЛЮБОЙ - с первого чтения мог понять : что где лежит и где найти то, что мне надо? (уж не говоря про перестройку логики работы)

А с чего бы это "любой с первого чтения" смог понять бы что-где лежит в ERP системе состоящей из 50-80 модулей. Вам с полгода надо будет что-бы разобраться в паре - тройке таких модулей.
...
Рейтинг: 0 / 0
14.10.2005, 09:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324147
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChВопрос для всех противников объектного слоя.
Как вы думаете, для чего существуют ORM-средства и кто ими пользуется?

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

VladiChДля обработки данных достаточно. Обработка данных и у меня в конечном итоге производится на TSQL. Но ведь бизнес-логика и обработка данных - это не совсем одно и то же, не правда ли? Бизнес-логика связана с определенными объектами реального мира, между которыми существуют определенные отношения. И моделировать всю эту систему в целом только посредством TSQL довольно неудобно.

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

VladiChЧто вы называете оптимальным кодом и структурой? А вы дадите гарантию, что вы генерите такой код и структуру вручную? А доказать можете?
А кто-нибудь вообще может дать такую гарантию? Какие-то странные вопросы вы задаете.

Оптимальная структура - структура, позволяющая обрабатывать хранящиеся в ней данные с максимальной производительностью. Оптимальный код - код имеющий наименьшее время выполнения при реализации требуемых алгоритмов. Вручную я как раз могу "вылизать" и структуру и код, потратив на эту оптимизацию дополнительное и, причем, немалое время, используя все возможности СУБД, которая используется. Не вижу в вопросе об "оптимальности" ничего странного. Более того, для OLTP систем оптимальность структуры и кода - основа успеха.
...
Рейтинг: 0 / 0
14.10.2005, 09:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324152
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChДа, назовите мне хотя бы парочку "современных ERP-систем", в которых не использовалась бы объектная бизнес-логика и сервер приложений. Желательно по-отдельности - в которых не используется одно и в которых не используется другое.

OEBS Вас устроит?! Там есть среднее звено, но это не более чем формзовый сервер. Про кол-во объектов в базе расказывать?
...
Рейтинг: 0 / 0
14.10.2005, 09:50
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324162
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklinА с чего бы это "любой с первого чтения" смог понять бы что-где лежит в ERP системе состоящей из 50-80 модулей. Вам с полгода надо будет что-бы разобраться в паре - тройке таких модулей.
Вот-вот - шаманство в чистом виде:
нахрена мне модули - если база одна на всех - мне структуру базы нужно понять. И на это не нужно "полгода" - если есть нормальное иерархическое описание (если так ненавистно слово "объектное") - такое описание читается сразу, и фактически - это есть описание бизнес-процессов (в некотором смысле).
...
Рейтинг: 0 / 0
14.10.2005, 09:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324184
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Я кажетца понял про ООП-БЛ, о которой говорит нам VladiCh .

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

Но помилуйте - это к бизнес-логике никак не относится.

А теперь самое интересное: про ООП-методы объекта - мы так и не выяснили, есть ли методы прямо на форме, как к ним можно обратиться, и вообще, как можно работать с чем-то и писать приложение, если ты заранее не знаешь, какие методы есть у объекта, какие параметры ему нужны и как вообще их можно исполнить.
Из-за этого пока что и нет понимания никакого.

Вот методы то относятся к БЛ.
И именно это мы просили много раз рассказать - не про то, что формы на лету генерятся, а про методы объектов и работу с ними, которые такие вот наскрозь ООП.

Пожалста, VladiCh, оставьте интерфейсную шелуху и расскажите нам про методы объектов - как я могу выполнить метод, не зная его, и где я его могу выполнить, если у меня нет даже собственной формы конкретного типа объектов.

Очень хочется узнать. Просто конкретный пример: есть объект, есть у него метод ХХХ, нужно его в определенном месте на форме списка этих объектов выполнить - как вы это сделаете?

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 10:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324199
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Пользователь Вот-вот - шаманство в чистом виде:
нахрена мне модули - если база одна на всех - мне структуру базы нужно понять. И на это не нужно "полгода" - если есть нормальное иерархическое описание (если так ненавистно слово "объектное") - такое описание читается сразу, и фактически - это есть описание бизнес-процессов (в некотором смысле).
Ну если вы вундеркинд, то вам на сцену а не сюда.
Мы то про обычных людей.
Если обычный человек - давайте, устройте нам показательное выступление: мы вам даем полное описание системы страниц на ...... 500 (это краткое описание), даем времени только на прочтение, после этого спрашиваем вас о любом процессе в системе - как он происходит, с какими процессами связан и как влияет на них и какие процессы и как влияют на него, в каком месте системы это все можно найти и почему именно там. Наверное вы сразу все нам и расскажете?
Правда мне кажется, что вы даже и не вспомните, о чем речь, не говорю уж об остальном.

Так что дурацкие замечания придержите для системы "Нотепад" :))

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 10:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324201
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
Давайте определимся, что такое БЛ?

А еще, у VladiCh не совсем реляционная БД (насколько я понял), а в таком варианте возможно действительно уже и без разницы как с БД работать :)

Пользователькак можно сопровождать систему из 100 тысяч ХП - без ОБЪЕКТНОГО (читай - иерархического) описания ? (причем желательно, чтобы происходила автоматическая синхронизация описания со всеми изменениями в базе)
Да так же - делим все на группы/области и описываем. Все равно, без текстового описания каждого свойства и метода и "обьектное" описание не информативно ни разу (имхо).

DrKonitoИмхо чтобы необходимость технологии представляющей новый уровень абстракции над "процедурным SQL" ... она действительно должна означать повышение производительности труда
Наверное, причина не обязательно д.б. в повышении производительности. Я тут подумал, использование обертки, действительно, может снизить требования к квалификации кодеров. По нынешним временам это важно.

Общался с коллегой, пришли к выводу, что в случае web-систем оправдано наличие доп. базы, в которой хранится описание интерфейса для разных групп пользователей. Плюс, если пользователей десятки-сотни тысяч, то, предположу, что вынесение в эту доп. базу некоторого security-функционала тоже м.б. оправдано (с т.з. повышения производительности).
...
Рейтинг: 0 / 0
14.10.2005, 10:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324205
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklin ПользовательОтвете всетаки простому труженику:
как можно сопровождать систему из 100 тысяч ХП - без ОБЪЕКТНОГО (читай - иерархического) описания ? (причем желательно, чтобы происходила автоматическая синхронизация описания со всеми изменениями в базе)

Можно. И такие системы сопровождаются, и без всякой объектной модели, хотя с некоторыми дополнительными наворотами, типа Workflow.

Что-то мне подсказывает, что мы о разных вещах говорим.

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

- или на крайний случай - без модели всей системы - понятной всем участникам процесса.

А в идеале - изменения в модели должны вызывать изменения в базе.
(и это все уже существует в мире - назывется управление регламентами компании).
...
Рейтинг: 0 / 0
14.10.2005, 10:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324218
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ПользовательВот-вот - шаманство в чистом виде:
нахрена мне модули - если база одна на всех - мне структуру базы нужно понять. И на это не нужно "полгода" - если есть нормальное иерархическое описание (если так ненавистно слово "объектное") - такое описание читается сразу, и фактически - это есть описание бизнес-процессов (в некотором смысле).

А модули на тот хер, что каждый модуль содержит объекты в своей схеме. И вся струтктура описана в виде ERD модели - той самой модели деятельности предприятия. А на счет то, что "структуру базы" Вам надо понять... трудновато будет ее понять без разделения на модули в системах с 10 ... 100 тысячами объектов.
...
Рейтинг: 0 / 0
14.10.2005, 10:15
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324228
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
tygra
Так что дурацкие замечания придержите для системы "Нотепад" :))

Ну вот я зная бизнес-процессы компании (и в некотором смысле их формирую) - и что :
гляжу на 100тыщ ХП - как баран на новые ворота -
зацепится то не за что.

И само печальное - что и разработчики системы имеют весьма хреновое представление - нет описания, правильного (читай - понятного сразу).
Есть описание всех таблиц, ХП - и что? что это дает ?
...
Рейтинг: 0 / 0
14.10.2005, 10:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324229
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
автор
Terrorist
В том то и дело, что более менее приемлимый код генериться, только для очень простых задач. И оправдано такое использование, только при создании приложений не зависящих от СУБД. Как только вы начинаете руками там что-то оптимизировать, сразу получаете зависимость от СУБД.
Других причин когда, то что можно сделать на СКЛ, делаеться, через ОРМ, я не вижу. Покажете?

Не согласен ни с тем, что такой подход годится только для очень простых задач, ни с тем, что при оптимизации я получаю зависимость от СУБД. При оптимизации не изменяется интерфейс между объектным ядром и клиентом, вся оптимизация проводится внутри СУБД. Откуда тогда зависимость от СУБД?
Насчет того что других причин не видите - ну вы не одиноки в этом. Причины я уже наверное раз 10 описывал...
Пример из жизни. Иерархическая структура в одной таблице.
Пример
table Document
Doc_id NUMBER PK,
DOC_DOC_ID number FK Document(DOC_ID)
В таблице было около 500 тыс. записей.
Нужно было выбрать ветку дерева от потомка к первому родителю.
ОРМ знаете что делал? Вытягивал каждый раз всю таблицу и сам по ней шарился. Пробывали разные ОРМ.
Потом оптимизировали, СУБД Оракл, есть замечательная конструкция START WITH.. CONNECT BY , для работы с древовидными структурами.
При работе клиента с ядром ничего не меняется, это правда. Но всё координально меняется при замене СУБД. Вам маппер нужно переделывать под каждую конкретную СУБД. Вы представляете себе как потом это сопровождать?
Не говоря уже о том, что я не видел маппера нормально работающего с ораклом. Некоторые при добавлении обьетка, вставляют запись со всеми NULL'ами и потом апдейтят поля... Все констрейнты в таком случае должны быть дефферед .... представляете как на клиенте ловить ошибки, когда на у вас транзакция на 10 инсертов? И с сиквенсами не все работать умеют ... думают, что везде первичные ключи автоинкрементные поля. :-\
ОРМ интересн в теории, но на практике это сплошной гемморой.
...
Рейтинг: 0 / 0
14.10.2005, 10:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324234
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ПользовательЯ имею ввиду, что для большой системы поддержка целостности (не базы - а бизнес-логики), непротиворечивости - при перестройках логики работы - уже невозможно без автоматической верификации (слово красивое)

- или на крайний случай - без модели всей системы - понятной всем участникам процесса.

А в идеале - изменения в модели должны вызывать изменения в базе.
(и это все уже существует в мире - назывется управление регламентами компании).

Эээ... И что?! Модель всей системы возможна только в случаи использования объектной ее модели?! Я уже писал выше про ERD модели. И с чего Вы решили, что то, что "существует во всем мире" может ипользоваться только для объектной модели?!
...
Рейтинг: 0 / 0
14.10.2005, 10:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324244
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Пользователь tygra
Так что дурацкие замечания придержите для системы "Нотепад" :))

Ну вот я зная бизнес-процессы компании (и в некотором смысле их формирую) - и что :
гляжу на 100тыщ ХП - как баран на новые ворота -
зацепится то не за что.

И само печальное - что и разработчики системы имеют весьма хреновое представление - нет описания, правильного (читай - понятного сразу).
Есть описание всех таблиц, ХП - и что? что это дает ?

Ёпрст... С чего Вы взяли что-такого опиcания нет?! Про модели повторяюсь в 3й раз!!! И про Workflow не зря я упомянул. Из него очень хорошо "видно" какие из хп в какой момент выполняются.
...
Рейтинг: 0 / 0
14.10.2005, 10:22
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324317
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
авторНу вот я зная бизнес-процессы компании (и в некотором смысле их формирую) - и что :
гляжу на 100тыщ ХП - как баран на новые ворота -
зацепится то не за что.

И само печальное - что и разработчики системы имеют весьма хреновое представление - нет описания, правильного (читай - понятного сразу).
Есть описание всех таблиц, ХП - и что? что это дает ?
А с методами не так? Ну будет у вас 100тыщ методов, что от этого поменяется?
...
Рейтинг: 0 / 0
14.10.2005, 10:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324602
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
Terrorist авторНу вот я зная бизнес-процессы компании (и в некотором смысле их формирую) - и что :
гляжу на 100тыщ ХП - как баран на новые ворота -
зацепится то не за что.

И само печальное - что и разработчики системы имеют весьма хреновое представление - нет описания, правильного (читай - понятного сразу).
Есть описание всех таблиц, ХП - и что? что это дает ?
А с методами не так? Ну будет у вас 100тыщ методов, что от этого поменяется?
Э, не скажите,
во первых будут не методы, а объекты и их методы.
во вторых - методы наследуются (в смысле следующий по иерархии объект добавляет только свои, специфические методы).
в третьих - объекты связанные - вплоть до корневого, и пройдя по цепочке можно дойти до любого объекта.
Ну и - я понимаю такое описание, по крайней мере я надеюсь, что в таком описании я смогу найти все, что мне нужно.
...
Рейтинг: 0 / 0
14.10.2005, 11:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324762
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraА теперь самое интересное: про ООП-методы объекта - мы так и не выяснили, есть ли методы прямо на форме, как к ним можно обратиться, и вообще, как можно работать с чем-то и писать приложение, если ты заранее не знаешь, какие методы есть у объекта, какие параметры ему нужны и как вообще их можно исполнить.
Из-за этого пока что и нет понимания никакого.
Да ради бога... Если вы думаете, что кроме формы со списком объектов в системе ничего больше нет, то вы ошибаетесь. Это был просто пример в ответ на ваш со списками объектов.
Да, на клиенте мы получаем полноценные объекты, из которых можем дергать методы, эти методы в результате обращаются к промежуточному слою, который затем лезет в БД. На эти методы повешена система security, которая позволяет или не позволяет конкретному пользователю выполнять конкретный метод. Для форм со списком/редактированием объектов все работает точно также, выполняются методы самого базового объекта Entity, который знает о том, как работать со всеми своими атрибутами. Другие формы разумеется тоже знают о методах объектов, с которыми должны работать. Преимущество в чем - в том, что эти методы работают не для одного типа объектов, а для всей иерархии объектов, унаследованных от данного типа. В случае с типом Entity - это вообще все объекты, т.к. все они от него унаследованы.

pkarklinOEBS Вас устроит?! Там есть среднее звено, но это не более чем формзовый сервер. Про кол-во объектов в базе расказывать?
Какие функции выполняет формзовый сервер? Неужели это именно он дергает хранимые процедуры из СУБД? И какой интерфейс он клиенту предоставляет?
...
Рейтинг: 0 / 0
14.10.2005, 12:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324767
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
ПользовательЭ, не скажите,
во первых будут не методы, а объекты и их методы.
во вторых - методы наследуются (в смысле следующий по иерархии объект добавляет только свои, специфические методы).
в третьих - объекты связанные - вплоть до корневого, и пройдя по цепочке можно дойти до любого объекта.
Ну и - я понимаю такое описание, по крайней мере я надеюсь, что в таком описании я смогу найти все, что мне нужно.
Ну и методы можно бездумно по обьектам порасскидывать. По-моему во всех СУБД есть способы сгруппировать ХП. В оракле это пакеты, в других незнаю.
Кстати, перегрузка функций там есть...
...
Рейтинг: 0 / 0
14.10.2005, 12:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324773
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklin
Ёпрст... С чего Вы взяли что-такого опиcания нет?! Про модели повторяюсь в 3й раз!!! И про Workflow не зря я упомянул. Из него очень хорошо "видно" какие из хп в какой момент выполняются.
(воспользуюсь хорошим моментом для собственного ликбеза)
Я правильно понимаю: приемный отдел - сажает товар, проводит документы - мы видим: "какие из хп в какой момент выполняются".
Но ведь такое описание невозможно без понятий: товар, предприятие, склады, - без понятий объектной модели: существуют объекты, которые участвуют в процессах. Это вроде две стороны одной медали (как обычно тут говорят - это те же яйца - только с разных сторон).
...
Рейтинг: 0 / 0
14.10.2005, 12:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324793
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ПользовательЭ, не скажите,
во первых будут не методы, а объекты и их методы.
во вторых - методы наследуются (в смысле следующий по иерархии объект добавляет только свои, специфические методы).
в третьих - объекты связанные - вплоть до корневого, и пройдя по цепочке можно дойти до любого объекта.
Ну и - я понимаю такое описание, по крайней мере я надеюсь, что в таком описании я смогу найти все, что мне нужно.
Удерживать систему от сползания в хаос можно не только при помощи ООП. ООП кстати тоже не оправдал надежд в этой области ;)

Никто не спорит, что ООП дает больше возможностей по структурированию кода. Но дает оно их не бесплатно.
Для меня очевидны проблемы с производительностью, интеграцией, эксплуатацией, незрелостью используемых технологий.
Слишком дорого, слишком мало преимуществ.
Повторюсь я имею в виду только область в которой работаю- самописные учетные системы на предприятии. В другой области могут быть другие акценты.
...
Рейтинг: 0 / 0
14.10.2005, 12:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324795
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh Какие функции выполняет формзовый сервер? Неужели это именно он дергает хранимые процедуры из СУБД? И какой интерфейс он клиенту предоставляет?

Ага. И запросы отправляет... Классический MDI интерфейс на основе апплетов.

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

Так. повторяюсь в 4й раз - ERD модель!!! Может, наконец, погуглите на предмет что это такое?!
...
Рейтинг: 0 / 0
14.10.2005, 12:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324796
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
TerroristПример из жизни. Иерархическая структура в одной таблице.
Пример
table Document
Doc_id NUMBER PK,
DOC_DOC_ID number FK Document(DOC_ID)
В таблице было около 500 тыс. записей.
Нужно было выбрать ветку дерева от потомка к первому родителю.
ОРМ знаете что делал? Вытягивал каждый раз всю таблицу и сам по ней шарился. Пробывали разные ОРМ.
Потом оптимизировали, СУБД Оракл, есть замечательная конструкция START WITH.. CONNECT BY , для работы с древовидными структурами.
При работе клиента с ядром ничего не меняется, это правда. Но всё координально меняется при замене СУБД. Вам маппер нужно переделывать под каждую конкретную СУБД. Вы представляете себе как потом это сопровождать?
Не говоря уже о том, что я не видел маппера нормально работающего с ораклом. Некоторые при добавлении обьетка, вставляют запись со всеми NULL'ами и потом апдейтят поля... Все констрейнты в таком случае должны быть дефферед .... представляете как на клиенте ловить ошибки, когда на у вас транзакция на 10 инсертов? И с сиквенсами не все работать умеют ... думают, что везде первичные ключи автоинкрементные поля. :-\
ОРМ интересн в теории, но на практике это сплошной гемморой.
Какие ORM вы пробовали? Попробуйте в конце-концов что-нибудь нормальное. То, что вы рассказываете - это конечно тихий ужас, не верю что вы использовали нормальную промышленную ORM. Может быть какую-нибудь open-source'ную недоделанную систему?
...
Рейтинг: 0 / 0
14.10.2005, 12:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324802
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinАга. И запросы отправляет... Классический MDI интерфейс на основе апплетов.
Я говорю не про UI, то бишь пользовательский интерфейс, а API, то бишь программный интерфейс.
...
Рейтинг: 0 / 0
14.10.2005, 12:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324813
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklin ПользовательЯ имею ввиду, что для большой системы поддержка целостности (не базы - а бизнес-логики), непротиворечивости - при перестройках логики работы - уже невозможно без автоматической верификации (слово красивое)

- или на крайний случай - без модели всей системы - понятной всем участникам процесса.

А в идеале - изменения в модели должны вызывать изменения в базе.
(и это все уже существует в мире - назывется управление регламентами компании).

Эээ... И что?! Модель всей системы возможна только в случаи использования объектной ее модели?! Я уже писал выше про ERD модели. И с чего Вы решили, что то, что "существует во всем мире" может ипользоваться только для объектной модели?!
(я конечно извиняюсь, что у Вас такая реакция на слово "объект")
но у меня в цитате выше нет ни одного слова "объект" (я уже боюсь его упоминать),
Модель - любая - но доступная для понимания, однозначно связанная с таблицами, ХП, и т.д. базы.
...
Рейтинг: 0 / 0
14.10.2005, 12:44
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324858
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 Пользователь
Я что-то не пойму - вам чего непонятно?
Кто вам сказал, что у нас нет модели системы? Вы откуда это взяли?
Причем тут ООП и модель системы?

Вы уж определите, о чем разговор.

У всех есть модель системы, которая каким-то образом связана и с ХП, и со всем остальным.
Возьмите ErWin, закачайте туда БД - отличная модель.

===================================

VladiCh Да ради бога... Если вы думаете, что кроме формы со списком объектов в системе ничего больше нет, то вы ошибаетесь. Это был просто пример в ответ на ваш со списками объектов.
Зачем приводить неудачный пример?
авторДа, на клиенте мы получаем полноценные объекты, из которых можем дергать методы, эти методы в результате обращаются к промежуточному слою, который затем лезет в БД. На эти методы повешена система security, которая позволяет или не позволяет конкретному пользователю выполнять конкретный метод. Для форм со списком/редактированием объектов все работает точно также, выполняются методы самого базового объекта Entity, который знает о том, как работать со всеми своими атрибутами. Другие формы разумеется тоже знают о методах объектов, с которыми должны работать. Преимущество в чем - в том, что эти методы работают не для одного типа объектов, а для всей иерархии объектов, унаследованных от данного типа. В случае с типом Entity - это вообще все объекты, т.к. все они от него унаследованы.
Да ёперный театр, ну сколько же можно? Ну хватит воды то - все знают принципы ООП.
Вас какой раз уже просят: покажите на примере, как у вас это работает - конкретно вызов метода объекта на форме , что при этом делается, где метод чего берет.
Я повторю свой вопрос:
tygraПожалста, VladiCh, оставьте интерфейсную шелуху и расскажите нам про методы объектов - как я могу выполнить метод, не зная его, и где я его могу выполнить, если у меня нет даже собственной формы конкретного типа объектов.

Очень хочется узнать. Просто конкретный пример: есть объект, есть у него метод ХХХ, нужно его в определенном месте на форме списка этих объектов выполнить - как вы это сделаете?

Будет ответ или нет? Или у вас такая страшная реализация, что не хотите рассказывать?

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 12:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324860
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChЯ говорю не про UI, то бишь пользовательский интерфейс, а API, то бишь программный интерфейс.

Програмный интерфейс предоставляют Oracle Forms и Oracle Reports, а формзовый сервер по функционалу типичный WEB сервер.
...
Рейтинг: 0 / 0
14.10.2005, 12:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324865
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
DrKonitoДля меня очевидны проблемы с производительностью, интеграцией, эксплуатацией, незрелостью используемых технологий.
Ну-ка поподробнее... Конкретно интересуют проблемы с интеграцией, эксплуатацией и незрелостью технологий. С производительностью - спорный вопрос, хотя с некоторыми оговорками готов согласиться...
...
Рейтинг: 0 / 0
14.10.2005, 12:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324868
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
pkarklin
Так. повторяюсь в 4й раз - ERD модель!!! Может, наконец, погуглите на предмет что это такое?!
Каюсь, посыпаю голову пеплом:
Диаграмма зависимостей сущностей (ERD)

Диаграмма зависимостей сущностей является моделью данных высокого (более общего) уровня.

Основной задачей Диаграммы зависимостей сущностей является обзор требований к бизнес-информации, достаточной для планирования разработки информационной системы. Эти модели не являются очень детализированными (в них включены только основные сущности), и почти отсутствуют атрибуты. Разрешены отношения многие-ко-многим, а ключи, в основном, не включаются. Одним словом, ERD является презентационной моделью, удобной для обсуждения.
----------
так там еще много красивых буковок:
Модель, основанная на ключах (KB).
Полностью определенная модель (FA).
DBMS модель
----------
По мне - хоть чертом лысым назови -
лишь бы: Модель,
1) понятна сразу (а не через пол-года), а значит структуировано, иерархическая.
2) однозначно связана с базой (таблицы, ХП, ...)
...
Рейтинг: 0 / 0
14.10.2005, 12:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324872
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklin VladiChЯ говорю не про UI, то бишь пользовательский интерфейс, а API, то бишь программный интерфейс.

Програмный интерфейс предоставляют Oracle Forms и Oracle Reports, а формзовый сервер по функционалу типичный WEB сервер.

Интересует, что в OEBS является клиентом, с каким сервером он работает и при помощи какого API.
...
Рейтинг: 0 / 0
14.10.2005, 12:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324888
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ПользовательДиаграмма зависимостей сущностей (ERD)

Диаграмма зависимостей сущностей является моделью данных высокого (более общего) уровня.

Это самый верхний уровень, с которого стоит "изучать" неизвестную систему. Нижнем уровнем в этой цепочке является физическая модель данных, где как раз те самые таблицы, триггера и т.п....
...
Рейтинг: 0 / 0
14.10.2005, 13:01
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324889
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh pkarklin VladiChЯ говорю не про UI, то бишь пользовательский интерфейс, а API, то бишь программный интерфейс.

Програмный интерфейс предоставляют Oracle Forms и Oracle Reports, а формзовый сервер по функционалу типичный WEB сервер.

Интересует, что в OEBS является клиентом, с каким сервером он работает и при помощи какого API.

WEB браузер, поддерживающий Java апплеты.
...
Рейтинг: 0 / 0
14.10.2005, 13:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324890
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
tygraВозьмите ErWin, закачайте туда БД - отличная модель.

Красиво сказано, видели, - и что? Структуру связей таблиц увидим - и что?
Таблиц - 1000, - кто за этим лесом что либо увидит?
...
Рейтинг: 0 / 0
14.10.2005, 13:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324896
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Работает, естественно, с Oraclовским сервером.
...
Рейтинг: 0 / 0
14.10.2005, 13:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324917
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
tygraВозьмите ErWin, закачайте туда БД - отличная модель.

Что можно увидеть за лесом из 1000 таблиц?
...
Рейтинг: 0 / 0
14.10.2005, 13:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324973
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinРаботает, естественно, с Oraclовским сервером.
А мне тут знающие люди говорят, что есть в OEBS App-сервер, называется Oracle iAS. И кто прав? Я сам в OEBS не разбираюсь, в оракловых продуктах очень слабо ориентируюсь, но мне кажется почти фантастикой, что в большой ERP-системе не используется applications server. Думаю, что-то вы тут недоговариваете или просто не в курсе.
...
Рейтинг: 0 / 0
14.10.2005, 13:22
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33324996
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Здесь подробнее есть про OEBS...
Так что вы действительно похоже не в теме...
...
Рейтинг: 0 / 0
14.10.2005, 13:27
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325031
Один1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Один1
Гость
Легкий офф

С интересом сейчас наблюдаю за развитием нового проекта (естественно ERP :) )
Разработчики решили применить все самые передовые технологии и приемы.

3-х уровневая архитектура
Бизнес логика на среднем уровне
Object-relational mapping
автогенерация UI на основе метаданных

средний уровень и UI - C# и VS 2005
СУБД - SQLServer 2005

Пока что прорабатываются концепции и отрабатываются взаимосвязи между различными частями приложения.
...
Рейтинг: 0 / 0
14.10.2005, 13:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325064
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiCh Здесь подробнее есть про OEBS...
Так что вы действительно похоже не в теме...

Можно узнать, как из этой статьи Вы сделали вывод о моей некомпетентности в этом вопросе.?! Вас смутил "Business Intelligence Server". Так это не тот элемент архитектуры, который отвечает за транзакционну часть системы. За нее отвечает:

Forms Server
Forms server — это компонент Oracle Developer, который позволяет приложениям на основе Oracle Forms производить изменения в базе данных. Forms сервер кэширует данные и предоставляет их клиенту по мере необходимости, например, при операциях прокрутки экрана. Связь с клиентским уровнем осуществляется по стандартному протоколу TCP/IP HTTP или HTTPS. Связь с уровнем базы данных осуществляется по протоколу Oracle Net8. Между несколькими Forms серверами используется автоматическая балансировка нагрузки. Клиентский запрос, таким образом, перенаправляется наименее загруженному в данный момент Forms серверу.
...
Рейтинг: 0 / 0
14.10.2005, 13:45
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325072
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Почти один-в-один с тем, чем занимаемся мы. Есть конечно некоторые отличия - мы больше ориентируемся на CMS и документооборот, нежели на ERP, это накладывает некоторый отпечаток на архитектуру системы. Ну и еще используется VS 2003 и MS SQL 2000. А в остальном - то же самое.
Ну и как у них успехи?
...
Рейтинг: 0 / 0
14.10.2005, 13:47
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325091
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinМожно узнать, как из этой статьи Вы сделали вывод о моей некомпетентности в этом вопросе.?!
Нет, ну если для вас Oracle Application Server - это не application server, то я даже и не знаю... Они его по крайней мере именно так позиционируют.
Что же для вас тогда вообще "серер приложений" ?

pkarklinForms Server
Forms server — это компонент Oracle Developer, который позволяет приложениям на основе Oracle Forms производить изменения в базе данных. Forms сервер кэширует данные и предоставляет их клиенту по мере необходимости, например, при операциях прокрутки экрана. Связь с клиентским уровнем осуществляется по стандартному протоколу TCP/IP HTTP или HTTPS. Связь с уровнем базы данных осуществляется по протоколу Oracle Net8. Между несколькими Forms серверами используется автоматическая балансировка нагрузки. Клиентский запрос, таким образом, перенаправляется наименее загруженному в данный момент Forms серверу.

ну так Forms server не выполняет ли некоторые функции сервера приложений?
также как и Business inteligence server и discoverer server?
...
Рейтинг: 0 / 0
14.10.2005, 13:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325178
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChНет, ну если для вас Oracle Application Server - это не application server, то я даже и не знаю... Они его по крайней мере именно так позиционируют.

Мы про термин "application server" говорим, или о примере многозвенного ERP приложения (OEBS), где НЕТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ?!

VladiChну так Forms server не выполняет ли некоторые функции сервера приложений?

Вы помните в каком разрезе я приводил Вам в качестве примера OEBS?! В плане отсуствия в ней ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ. Forms Server НЕ СОДЕРЖИТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ.

автортакже как и Business inteligence server и discoverer server?

Там тоже НЕТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ.
...
Рейтинг: 0 / 0
14.10.2005, 14:13
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325186
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
VladiCh pkarklinМожно узнать, как из этой статьи Вы сделали вывод о моей некомпетентности в этом вопросе.?!
Нет, ну если для вас Oracle Application Server - это не application server, то я даже и не знаю... Они его по крайней мере именно так позиционируют.
Что же для вас тогда вообще "серер приложений" ?

iAS это апач + mod_plsql, насколько я знаю, там нет ОРМ и еБизнесСьют его не использует. И это название просто маркетинговый ход компании оракл. :)
Формс в данном случае, это клиент (причем это ПЛ/СКЛ клиент), а бизнес логика на сервере ... в куче пакетов зарыта.
...
Рейтинг: 0 / 0
14.10.2005, 14:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325279
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklin VladiChНет, ну если для вас Oracle Application Server - это не application server, то я даже и не знаю... Они его по крайней мере именно так позиционируют.

Мы про термин "application server" говорим, или о примере многозвенного ERP приложения (OEBS), где НЕТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ?!

VladiChну так Forms server не выполняет ли некоторые функции сервера приложений?

Вы помните в каком разрезе я приводил Вам в качестве примера OEBS?! В плане отсуствия в ней ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ. Forms Server НЕ СОДЕРЖИТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ.

автортакже как и Business inteligence server и discoverer server?

Там тоже НЕТ ОБЪЕКТНОЙ МОДЕЛИ БИЗНЕС-ЛОГИКИ.

Да ладно, зачем кричать-то, я вроде не глухой :).
Я вообще-то Вам два вопроса задавал, если помните, Вы ответили только на один из них. Второй вопрос был насчет ERP без сервера приложений.
Напомню еще раз вопрос:
VladiChДа, назовите мне хотя бы парочку "современных ERP-систем", в которых не использовалась бы объектная бизнес-логика и сервер приложений. Желательно по-отдельности - в которых не используется одно и в которых не используется другое.

Объектная бизнес-логика действительно не используется - ну что же, это минус для OEBS :). Говорят опять же, что разработка под него более трудоемка по сравнению с системами с объектной бизнес-логикой типа той же Axapta...
...
Рейтинг: 0 / 0
14.10.2005, 14:39
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325287
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Terrorist VladiCh pkarklinМожно узнать, как из этой статьи Вы сделали вывод о моей некомпетентности в этом вопросе.?!
Нет, ну если для вас Oracle Application Server - это не application server, то я даже и не знаю... Они его по крайней мере именно так позиционируют.
Что же для вас тогда вообще "серер приложений" ?

iAS это апач + mod_plsql, насколько я знаю, там нет ОРМ и еБизнесСьют его не использует. И это название просто маркетинговый ход компании оракл. :)
Формс в данном случае, это клиент (причем это ПЛ/СКЛ клиент), а бизнес логика на сервере ... в куче пакетов зарыта.
Плохо знаете, использует, посмотрите статью по ссылке, указанной мной выше.
...
Рейтинг: 0 / 0
14.10.2005, 14:41
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325341
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
И вот мы, наконец, подошли к самому главному выводу. Что если среднее звено не имеет объектной модели, то это не сервер приложений&! Это все, как правильно заметил Terrorist, маркетинговые ухишрения. Вот статейка хорошая на эту тему: Сервер приложений – не пуп Земли?
...
Рейтинг: 0 / 0
14.10.2005, 14:50
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325396
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Вы пришли к такому выводу? Ну что же, я рад за Вас.
Я пришел к другому выводу - если приложение не имеет объектной модели бизнес-логики, то его сложнее расширять и поддерживать. Сервер приложений в этом плане мне довольно параллелен. Сервер приложений нужен по другим причинам: он имеет значение для приложений с большим количеством пользователей, а также в качестве физического уровня абстракции - от СУБД например. Он позволяет частично разгрузить СУБД и клиента и распарралелить некоторые операции.
Причем если у него не объектный/компонентный интерфейс с клиентом, как например в OEBS, то сложнее становится сделать систему независимой от СУБД. Для OEBS такая задача и не ставилась, зато к примеру та же Axapta прекрасно работает как с MS SQL, так и с Oracle.
...
Рейтинг: 0 / 0
14.10.2005, 15:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325401
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
А статейка хорошая в плане классификации серверов приложений.
...
Рейтинг: 0 / 0
14.10.2005, 15:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325426
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 VladiCh

Вы пример то будете приводить или все же стесняетсь?

Ну и по поводу
VladiCh если приложение не имеет объектной модели бизнес-логики, то его сложнее расширять и поддерживать.
Комментарий пожалуйста - что есть такое объектная модель бизнес-логики ? Для необъектной СУБД очень даже интересно послушать.

Повторяю на всякий случай, а то ... :)) :
Вы когда нибудь перестанете лить воду и будете отвечать по существу?

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 15:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325430
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
VladiCh Terrorist
iAS это апач + mod_plsql, насколько я знаю, там нет ОРМ и еБизнесСьют его не использует. И это название просто маркетинговый ход компании оракл. :)
Формс в данном случае, это клиент (причем это ПЛ/СКЛ клиент), а бизнес логика на сервере ... в куче пакетов зарыта.
Плохо знаете, использует, посмотрите статью по ссылке, указанной мной выше.
Ткните меня в номер строки в которой написано, что ОЕБС использует ОРМ!
нет там такого, статья написана умными словами, но к сожалению в реалиях красивыми словами закрыли _простые_ решения. И я бы не сказал, что последнии веяния(Формс сервер) является красивым.

Это всё равно как если бы вы запустили sql-консоль на удаленной машине, и работаете с ним, через локальный Х клиент(или терминал сервер).
Улавливаете в чем подвох? :)
А на словах все красиво ... сервер приложений ... там сервер репортофф ...
В предыдущей версии все работало(клиент-сервер) .... и обратную совместимость нужно тянуть за собой .....
не будет там ОРМ...
Формсы пишуться на языке ПЛ/СКЛ ... не жаба :) .... тот же язык что и для ХП в оракле...
Вы себе представляете маппер ... к которому из формс на СКЛе обращаються? :)
...
Рейтинг: 0 / 0
14.10.2005, 15:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325459
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
VladiChЯ пришел к другому выводу - если приложение не имеет объектной модели бизнес-логики, то его сложнее расширять и поддерживать.

И это вывод подкреплен опытом поддержки и расширения таких систем?

VladiChСервер приложений в этом плане мне довольно параллелен. Сервер приложений нужен по другим причинам: он имеет значение для приложений с большим количеством пользователей, а также в качестве физического уровня абстракции - от СУБД например.

Вы сами себе противоречите ("параллелен"). Вы обосновывали необходимость применения сервера приложений необходимстью применения объектной модели БЛ, реализовать которую в СУБД не просто. А объектная модель - это и есть тот самый уровень абстракции.

VladiChзато к примеру та же Axapta прекрасно работает как с MS SQL, так и с Oracle.

Не надо только про "прекрасность" расказывать!!!
...
Рейтинг: 0 / 0
14.10.2005, 15:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325466
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
VladiCh Сервер приложений нужен по другим причинам: он имеет значение для приложений с большим количеством пользователей, а также в качестве физического уровня абстракции - от СУБД например. Он позволяет частично разгрузить СУБД и клиента и распарралелить некоторые операции.
Причем если у него не объектный/компонентный интерфейс с клиентом, как например в OEBS, то сложнее становится сделать систему независимой от СУБД. Для OEBS такая задача и не ставилась, зато к примеру та же Axapta прекрасно работает как с MS SQL, так и с Oracle.
Согласен, но это совсем не означает использование ОРМ. Во первых тут есть необходимость совмещать два разных подхода к структурам данных, и почти всегда возникают конфликты. В результате надо либо делать кривые обьекты либо ложить на нормализацию в БД, и то и другое плохо. В результате появляются кривые решения.
И выносить операции в Апп-сервер(я бы сказал во внешние процедуры), только когда их реализация, не оптимальна (время разработки, скорость выполнения, и.т.д).
А большое кол-во пользователей понятие относительное ..... промышленная СУБД должна выдерживать тысячи и сотни тысяч пользователей.
...
Рейтинг: 0 / 0
14.10.2005, 15:22
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325471
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
2Terrorist.
Я не про маппер, а про использование iAS из OEBS.
Если я Вас неправильно понял - приношу свои извинения.
...
Рейтинг: 0 / 0
14.10.2005, 15:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325511
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Что-то VladiCh зрение потерял - не видит вопросы

Тогда можно заключить вот что: VladiCh сам не знает, как в его системе бизнес-логика устроена. Нет, проООП вообще он знает, и про то, что каким-то образом формы генерятся, нужно только в нужном месте поля добавить - это он понял, и что методы тоже можно вызывать - понял. Но как оно внутре устроено относительно методов - упссс, тут он знает, что как-то оно там все ООП-нутое , но как именно - не понимает. Но все работает, потому что так устроено - чтобы и дурак смог. :)

Иначе я не могу обосновать отказ VladiCh от конкретного примера использования и работы методов.

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 15:31
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325531
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
pkarklinИ это вывод подкреплен опытом поддержки и расширения таких систем?
Да, страниц 10 примерно назад я об этом писал...
pkarklinВы сами себе противоречите ("параллелен"). Вы обосновывали необходимость применения сервера приложений необходимстью применения объектной модели БЛ, реализовать которую в СУБД не просто. А объектная модель - это и есть тот самый уровень абстракции.
В каком месте я сам себе противоречу? Я здесь больше отстаивал объектную бизнес-логику нежели сервер приложений. Объектная модель - это один уровень абстракции, сервер приложений - другой. Объектная модель может нормально жить и на клиенте.
tygraКомментарий пожалуйста - что есть такое объектная модель бизнес-логики? Для необъектной СУБД очень даже интересно послушать.
tygra, я только одного не могу понять - сколько раз можно переливать из пустого в порожнее? Уже 55 раз все объяснено и показано - нет, вопросы по кругу идут...
...
Рейтинг: 0 / 0
14.10.2005, 15:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325538
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraТогда можно заключить вот что: VladiCh сам не знает, как в его системе бизнес-логика устроена. Нет, проООП вообще он знает, и про то, что каким-то образом формы генерятся, нужно только в нужном месте поля добавить - это он понял, и что методы тоже можно вызывать - понял. Но как оно внутре устроено относительно методов - упссс, тут он знает, что как-то оно там все ООП-нутое, но как именно - не понимает. Но все работает, потому что так устроено - чтобы и дурак смог. :)

Г-н tygra, просьба ваши домыслы оставить при себе, разговор в таком стиле мне совершенно неинтересен.
...
Рейтинг: 0 / 0
14.10.2005, 15:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325558
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторГ-н tygra, просьба ваши домыслы оставить при себе, разговор в таком стиле мне совершенно неинтересен.
Конечно - вам же сказать нечего.
Вы же сами то не знаете - только понты гнуть, а как до конкретики дошло - упс, облом, глухота, зрение плохое, отговорки.

авторtygra, я только одного не могу понять - сколько раз можно переливать из пустого в порожнее? Уже 55 раз все объяснено и показано - нет, вопросы по кругу идут...
Ткните мордой меня - где вы показали то, о чем я спрашиваю
Тогда я отвяжусь.

А пока что вы гнете понты и только. И знаете вашу систему не больше, чем я знаю вашу же систему.

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 15:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325618
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
VladiCh2Terrorist.
Я не про маппер, а про использование iAS из OEBS.
Если я Вас неправильно понял - приношу свои извинения.
Я поэтому и написал, что iAS(apache+mod_plsl+mod_java) это не та трехзвенность, которую мы тут рассматриваем....
Хотя может, и я не правильно что-то понял...
Необходимо четко определиться, что считать 3=-х звенной архитектурой ...... тут не раз вылазили названия драйвер и.т.п. ....
Я не спец в построении теорий и придумывании определений, но попытаюсь всё таки что-то подобное наваять.
Для меня 3-х звенная архитектура:
Наличие приложения которое производит бизнесс-процессы с данными на их пути от приложения клиента до СУБД. Конвертация данных не является полноценным бизнес-процессом(так мы действительно до драйвера сетевухи дойдем).
Наверное можно чётко сказать на какой диаграмме в УМЛ ... это должно быть вписанно.. я в УМЛ не силен :(
Наличие ОРМ для бизнес-данных в таком приложении наверное являеться обязательным, что бы можно было считать его 3-х звенным(ОРМ может быть самописным и специализированным под конкретную задачу). А так же, я считаю, обязательным является полная независимость приложения клиента от СУБД.
Просто хочеться выкинуть случаи когда 3-тим слоем называют ВЕБ-сервер( это как раз и делают маркетанты из оракл).
...
Рейтинг: 0 / 0
14.10.2005, 15:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325689
Пользователь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пользователь
Участник
tygra2 VladiCh

Вы пример то будете приводить или все же стесняетсь?


молодой, горячий, зеленый (и все в плюс однако)
...
Рейтинг: 0 / 0
14.10.2005, 16:16
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325722
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Пользователь молодой, горячий, зеленый (и все в плюс однако)
Эк вы как о себе! Я бы не стал так на вашем месте

-------------

Я смотрю, конкретика всех апологетов ООП_БЛ положила на лопатки.

Это хорошо, будем знать, что конкретика - хорошее оружие, массового поражения :)

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 16:25
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325746
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygra
tygraКомментарий пожалуйста - что есть такое объектная модель бизнес-логики? Для необъектной СУБД очень даже интересно послушать.
Ткните мордой меня - где вы показали то, о чем я спрашиваю
Тогда я отвяжусь.
Объектная модель бизнес-логики - это объектная модель бизнес-логики. Вам непонятен термин "объектная модель" или "бизнес-логика"? Вы действительно этого термина не знаете или прикидываетесь? Это модель бизнес-логики, выраженная в терминах объектов. Эти объекты могут существовать в среднем слое или на клиенте, в моем случае в среднем слое.

Какой вам нужен пример применения? Например CRM, часть, связанная с хранением информации о заказах. Заказ в процессе работы с клиентом проходит несколько этапов:
1. Заявка
2. Счет
3. Заказ
Это разные сущности системы, у которых в принципе разный набор атрибутов, есть базовый класс, от которого они все наследуются. Список товаров, которые заказываются, привязаны к базовому классу. Список операций тоже разный, но есть одни и те же операции, существующие на уровне базового класса, например добавить новый товар к списку товаров, откорректировать цену на товар (применимо для счета и заказа). При этом некоторые операции для разных типов объектов действуют по-разному. Например, изменение цены для товара в заказе должно отражаться на статусе заказа, а изменение цены в счете не отражается, т.к. поля “статус заказа” в нем вообще нет.
Формы на клиенте тоже разные, но наследуются от одной базовой с добавлением вызовов операций, специфических для данного объекта.
В принципе, так как список доступных операций хранится в метаданных с описанием и типами параметров, можно было бы обойтись вообще одной универсальной формой на все случаи жизни, ну или почти на все :). Это конечно утопия, но я думаю здравое зерно здесь тоже есть, надо попробовать что-нибудь сделать в этом направлении.

Еще нужны примеры?
Вот примеры, которые я уже приводил:
/topic/218568&pg=8#1958457
/topic/218568&pg=12#1961995
Вы от меня наконец отвяжитесь?

tygraА пока что вы гнете понты и только. И знаете вашу систему не больше, чем я знаю вашу же систему.
Ну разумеется, вам наверное виднее... Телепатов и ясновидящих здесь навалом, присоединяйтесь…
А вообще вы выбрали довольно некрасивую тактику – после демонстрации убогой архитектуры вашей системы, показать какие-то преимущества которой вы даже и не пытались, обвинять меня в том, что я и в своей-то системе не разбираюсь. Доказать это вы не в состоянии, так хотя бы покричать погромче. Кто громче кричит, того лучше слышно…
...
Рейтинг: 0 / 0
14.10.2005, 16:33
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325782
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
VladiCh
Тигра, конечно, молодой, горячий и зеленый.
Но!
Я, например, тоже никах примеров по вынесению БЛ в СП от Вас так и не увидел. Забейте на Тигру, опишите пример мне :).
Про секьюрити леер - это к БЛ отношения, в общем-то, не имеет.
Про ценообразование было сказано, что типа "вот оно сложное есть и поэтому мы его в СП вынесли", однако описания конкретной последовательности действий приведено так и не было. Я лично продолжаю полагать, что в СП вы этот расчет вынесли, т.к. не смогли это по каким-то причинам реализовать это в БД, что вовсе не означает, что так делать правильно.
...
Рейтинг: 0 / 0
14.10.2005, 16:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325806
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Епрст .......

Нам не надо читать лекции про теорию ООП.
Было спрошено: конкретный пример работы, с вызовом метода, как его вызвать, как его найти и т.д. Это не понятно чтоли?

Более того, то вы рассказываете, что все у вас генерится автоматически, то теперь уже не так - Формы на клиенте тоже разные

Ладно, не мне, Инженеру расскажите с примером.

-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 16:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325815
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 Инженер
Эх, если бы сейчас туда, когда был молодым, горячим и зеленым...........
Столько раз дураком бы не был.......

Но не вернуть время. Пока машину времени не сделали :))

С другой стороны хорошо - как саперы, если наступил, то все... :)


-- Tygra's --
...
Рейтинг: 0 / 0
14.10.2005, 16:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325865
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ИнженерЯ, например, тоже никах примеров по вынесению БЛ в СП от Вас так и не увидел.
Тигра от меня добивался конкретного примера использования объектов, вы же то меня тут другого добиваетесь :)
Ладно, я расскажу, каким образом БЛ вынесена в средний слой.
В "тигриной" терминологии, средний слой действительно представляет собой "толстый драйвер", выполняющий преобразование данных в другой формат и кэширование, некоторую внутреннюю оптимизацию . Система имеет 2 пользовательских интерфейса - веб-интерфейс и десктоп-интерфейс. Средний слой функционирует на веб-сервисах и веб-интерфейс работает с ним напрямую, без промежуточного звена. Логически разделение остается на 3 слоя, но физически веб-интерфейс работает с компонентами среднего слоя без сетевого подключения, просто используя ту же .NET-сборку, что и веб-сервисы. Десктопное приложение в результате использует то же API, что и веб-приложение, но данные объектов сериализуются в SOAP и десериализуются на клиенте.
Так что, СП у меня фактически виртуальный, по крайней мере в случае веб-интерфейса. Хотя это сделано исключительно из целей повысить производительность веб-интерфейса и в принципе из веб-приложения есть возможность работать также через веб-сервисы.
.NET-сборка с интерфейсами объектов живет как на клиенте, так и на среднем слое. На клиенте в случае WinForms для нее создается обертка для клиентской часть веб-сервиса, на сервере - для серверной. В случае WebForms вызов идет напрямую.
Как проиходит процесс создания нового объекта:
Я описываю в БД новый тип, его атрибуты и методы, при этом могу сгенерить код-заглушку для класса (если требуется, т.к. в принципе, я могу работать с любым объектом через базовый класс Entity, получить у него список методов, список параметров у метода, вызвать нужный метод и т.п., но это неудобно в случае, если на него навешана своя бизнес-логика).
Насчет того, как найти метод и вызвать его - зачем мне его искать, когда при выполнении запроса на выбор списка объектов, если например в списке разнотипные объекты, то на клиенте я получу их уже типизированными, с нужными методами, после того как вызову определенный метод будет вызван нужный веб-сервис и т.п.
...
Рейтинг: 0 / 0
14.10.2005, 17:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325887
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Про ценообразование не говорилось, что оно сложное. Там речь совсем о другом шла. Сложным я там называл разбор свеого языка запросов, который в нашей системе используется. Если я хочу выбрать список каких-нибудь объектов, я выполняю запрос на своем языке, который разбирается в среднем слое и конвертируется в соответствующий SQL, при этом м.б. указаны связи, описанные в метаданных, по этим связям могут быть загружены дочерние объекты. Если дочерние объекты по связям не загружены, то в зависимости от того, как происходит обращение, может происходить "ленивая" загрузка при обращении к полю объекта, содержащему ссылку на другой объект.
Затем результата выполнения этого SQL преобразуется в список объектов.
...
Рейтинг: 0 / 0
14.10.2005, 17:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325898
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
VladiCh
Мдя Я Вам про Фому, а Вы мне про Емелю :)
Мне не интересно, как (и зачем) устроена обьектная "обертка".
Я вполне согласен с тем, что она ("обертка") имеет право на существование .
Меня интересует пример (алгоритм взаимодействия СУБД-СП-Клиента) с расчетом цен в СП и дальнейшая судьба расчитанных данных. Или любые другие такие примеры, когда на основании полученного набора данных от СУБД, СП совершает какую-либо обработку (расчет, преобразование) и полученный результат отдает клиенту или на основании результата обработки совершает какие-либо изменения в БД. Все остальное в рамках этой темы меня не интересует (пока ).
...
Рейтинг: 0 / 0
14.10.2005, 17:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325970
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
Ну так Вы прочитайте внимательно, я написал, что на настоящий момент расчеты в СП не проводятся. Я неоднократно писал, что в результате логика все равно работает внутри базы данных, а СП выполняет вспомогательные функции + на нем живет объектный слой. В принципе такие расчеты можно проводить, просто в нашем случае возникают проблемы с ними. Например, с тем же ценообразованием. У нас расчет цены производится в момент выборки из БД, потому что иначе очень медленно будет работать поиск/сортировка по полю "цена" на уровне СП, т.к. расчет быстро выполняется для одного товара, но для нескольких тысяч при расчете на уровне СП это будет не быстро. Здесь действительно SQL рулит.
Если бы такого требования не было и достаточно было выполнять поиск/сортировку по хранящейся в БД базовой цене, то вполне реально и довольно удобно было бы расчет цены производить в СП и отдавать клиенту. Т.е. загружать список скидок для товара/группы отображаемых товаров и на уровне СП расчитывать цену. Если бы скидки не были индивидуальными для каждого клиента, можно было бы пересчитывать их в момент изменения для всех товаров, т.к. не так часто они меняются и так же хранить в БД. Но этот вариант у нас тоже не проходит.
...
Рейтинг: 0 / 0
14.10.2005, 17:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33325992
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
Я писал, когда Вашего предыдущего моему поста еще не было - это ж очевидно ;)
Мой пост актуален начиная со слов " Или любые другие..."
...
Рейтинг: 0 / 0
14.10.2005, 18:06
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326011
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
В моем предыдущем посте содержится ответ на Ваш вопрос -
VladiChЯ неоднократно писал, что в результате логика все равно работает внутри базы данных, а СП выполняет вспомогательные функции + на нем живет объектный слойДобавлю только, что я не исключаю, что какую-то часть расчетов надо будет выносить в СП и пример этого привел в том же посте.
...
Рейтинг: 0 / 0
14.10.2005, 18:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326013
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
Гы. Последние пять-шесть-семь страниц препирательств - все впустую
Тема СП, я думаю, раскрыта.
...
VladiChЕсли бы такого требования не было и достаточно было выполнять поиск/сортировку по хранящейся в БД базовой цене, то вполне реально и довольно удобно было бы расчет цены производить в СП и отдавать клиенту. Т.е. загружать список скидок для товара/группы отображаемых товаров и на уровне СП расчитывать цену. Если бы скидки не были индивидуальными для каждого клиента, можно было бы пересчитывать их в момент изменения для всех товаров, т.к. не так часто они меняются и так же хранить в БД.

Наверное, при всех оговорках, действительно удобно и быстро.
Только реальность, что в БД еще удобней и быстрее :D
Не говоря о накладных расходах на гоняние трафика в обе стороны.
...
Рейтинг: 0 / 0
14.10.2005, 18:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326015
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
тот жея не исключаю, что какую-то часть расчетов
балин, опять двадцать пять. НАПРИМЕР?!?!?! :D
...
Рейтинг: 0 / 0
14.10.2005, 18:19
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326038
Инженер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Инженер
Участник
Инженер тот жея не исключаю, что какую-то часть расчетов
балин, опять двадцать пять. НАПРИМЕР?!?!?! :D
этот пост не считается, сорри
предыдущего достаточно.
...
Рейтинг: 0 / 0
14.10.2005, 18:34
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326045
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
ИнженерГы. Последние пять-шесть-семь страниц препирательств - все впустую
Ну почему впустую? Тут в основном тема объектного слоя обсуждалась, а не СП, несмотря на название топика :). И она, как я понял, еще не закончена :).

Инженербалин, опять двадцать пять. НАПРИМЕР?!?!?! :D
Ну Вы же сами процитировали. Да, в целом со множествами работать в SQL быстрее и удобнее, но это проявляется на больших объемах. Если же объемы небольшие, а алгоритмически вычисления сложные, то удобнее их выполнять на сервере приложений. Это общие соображения, совсем конкретный пример я сейчас вряд ли приведу, надо подумать. Ну к примеру, если в ходе таких вычислений никак не обойтись без временных таблиц/курсоров и т.п. И не надо говорить про криво спроектированную БД - такие задачи все-таки существуют.
...
Рейтинг: 0 / 0
14.10.2005, 18:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326239
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
VladiCh.
> ... Это общие соображения, совсем конкретный пример я сейчас вряд ли приведу, надо подумать. Ну к примеру, если в ходе таких вычислений никак не обойтись без временных таблиц/курсоров и т.п. И не надо говорить про криво спроектированную БД - такие задачи все-таки существуют.

Здесь: http://www.sql.ru/forum/actualthread.aspx?tid=214017&pg=6
обсуждался аналогичный вопрос.
Приведу свой пример.

>Здравствуйте, Валентин.
>Похоже, мы вряд ли поймем друг друга, но попытка не пытка. Хочу привести >один пример из жизни. Заранее оговариваюсь, то в то время этой задачи не >решил.
>В конце 70-х занимался автоматизацией одного хим. процесса. "Горшок", в >него наливают, мешают, добавляют, вообшем варят "кашу", не пшонку >конечно. В колбах все прекрасно, а далее тормоз.
>Самой собой, все злые как собаки. Наука требует одно, технологи творят >другое, а аппаратчики как обычно - свое. Никакой воспроизводимости.
>Наш главный ногами топает - все технологические данные в базу данных и >хранить. Циклы съема от 2 до 10 секунд. Да и параметров в районе десятка. >Сейчас это ерунда, тогда - другое дело. Горшок в Навои, наука в >Ленинграде. Науке требуются кривые. Передать такой объем данных по тем >линиям связи не смогли. Какая то умная голова выдала, если им требуются >графики, то давайте аппраксимируем сплайном. При этой идее сжатие >тысяче кратное. Очень красиво - передавать только параметры сплайна. >Причем сплайн строится по выборке и её размер можно варьировать, задавая >временной интервал, и можно поднимать точность аппроксимации. Сейчас, >имея прототип, я бы её решил.
>База данных, здесь не пуп земли.
>Не знаю, на сколько удобно применять, например, T-SQL для задач >вычислительной математики.
>Чем хорош здесь .Net - могу применять разные молули из разных языков. >Больше всего интересна связь C# и Fortran.
>Смею заметить, что такие задачи есть. Мы просто не умеем их готовить.
>
>С уважением, Владимир.

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

Как эту задачу решил для MSSQL опубликовано
здесь: http://www.gotdotnet.ru/LearnDotNet/NETFramework/223738.aspx

Сейчас склоняюсь к мысли передавать поля (ключ, сортировочное) на сервер приложения и строить страницу там. Посмотрю скорость.

С уважением, Владимир.
...
Рейтинг: 0 / 0
15.10.2005, 00:13
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326655
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеев
Меня весьма серьезно интересует вопрос, как разные SQL сервера держат нагрузку при построении страниц из отсортированных выборок из всей таблицы (число записей большое(очень), число одновременных запросов также).
Cейчас склоняюсь к мысли передавать поля (ключ, сортировочное) на сервер приложения и строить страницу там. Посмотрю скорость.
Это чистый оффтоп- тема описывается в FAQ в форуме по MS SQL.
...
Рейтинг: 0 / 0
15.10.2005, 21:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326727
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
DrKonito.
>Это чистый оффтоп- тема описывается в FAQ в форуме по MS SQL.

Почти исчерпывающая информация по данному вопросу для MSSQL представлена здесь
/topic/179930&pg=18

Но хотелось получить и по другим, в первую очередь по Oracle, популярным серверам данных.

С уважением, Владимир.
p.s. Если можно, приводите пожалуйста ссылки.
...
Рейтинг: 0 / 0
15.10.2005, 23:09
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326878
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ВМоисеевDrKonito.
Но хотелось получить и по другим, в первую очередь по Oracle, популярным серверам данных. Офтоп 100%. Для этого есть форумы по соответствующим СУБД.
...
Рейтинг: 0 / 0
16.10.2005, 13:42
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326880
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Инженер
DrKonitoИмхо чтобы необходимость технологии представляющей новый уровень абстракции над "процедурным SQL" ... она действительно должна означать повышение производительности труда
Наверное, причина не обязательно д.б. в повышении производительности. Я тут подумал, использование обертки, действительно, может снизить требования к квалификации кодеров. По нынешним временам это важно.
А вы пробовали это делать? Я имел возможность сначала наблюдать, а потом заниматься этим на практике :)

Вы 400х долларового кодера видели? Обычно это человек год-другой поработавший на штуке типа Ацесса, ПХП или Икселевского ВБА.
Бэкграунд совершенно непредсказуем. Например человек может совершенно не знать, что такое реестр. Обычно бывает базовое понятие о синтаксисе SQL, если этого нет - то номер совсем дохлый. Понимание ООП обычно присутствует на уровне рассказывания на собеседовании вызубренных накануне определений наследования, полиморфизма и инкапсуляции.
Большой минус- очень трудно выбирать- потому, что все что человек знает вобщем-то не имеет значения :) Ему придется учиться заново.

Перед вами стоит задача, получить от такого персножа какую-нибудь пользу для проекта.
Как думаете, вы сможете быстро объяснить такому человеку ФирменнуюОченьПростуюОбъектнуюМодель?
Или дать ему ПодробныйУчебникПоФирменнойОбъектнойМодели, прочитав который он вольется в работу?
Не надейтесь- ВСЕГДА требуется выделенный тренер и несколько недель обучения. Даже если работа организована по принципу "кто выплывет", кто-то все-равно должен будет отвечать на вопросы.
Если думаете, что после этого вы получили полноценного кодера для проекта, то ошибаетесь. У таких людей отсутвует самое главное- ПониманиеТогоКакСистемаРаботает.
При малейшем отклонении от того, что было в учебных примерах работа встает и наступает либо ДолгийТормоз либо ДоставаниеВсехВстречныхТупымиВопросами.
Реально есть у вас выделенный тренер или нет, кто-то подобрее будет большую часть рабочего дня поддерживать ДешевыхКодеров.
Первые сдвиги появляются через пол-года\год в зависимости от умственных способностей подопытных.
Только тогда человек становится пригоден к реально самостоятельной работе. Это не значит, что они начали ПониматьКакВсеЭтоРаботает. Просто они набрали достаточно опыта, чтобы выход от них стал больше входа :) Соответственно, при любой нетривиальной проблеме они будут отвлекать тех кто реально делает работу.
Хорошая новость: через год-полтора-два понимание понимание начнет появляться. Вопрос в том, готовы ли вы ждать столько времени?

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

Вобщем, это для меня "снижение квалификации кодеров" в случае объектных оберток бизнес-логики- типичный миф.
Я это видел своими глазами- не рекомендую. Решайте сами.
...
Рейтинг: 0 / 0
16.10.2005, 13:46
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326885
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiCh ИнженерГы. Последние пять-шесть-семь страниц препирательств - все впустую
Ну почему впустую? Тут в основном тема объектного слоя обсуждалась, а не СП, несмотря на название топика :). И она, как я понял, еще не закончена :).
Тема объектного слоя рано или поздно приводит либо к логике в клиенте, либо к выделенному СП. Первый вариант, я думаю, малоинтересен :)
Так что говоря об "объектном слое" реально приходится говорить о сервере приложений.

VladiCh DrKonitoДля меня очевидны проблемы с производительностью, интеграцией, эксплуатацией, незрелостью используемых технологий.
Ну-ка поподробнее... Конкретно интересуют проблемы с интеграцией, эксплуатацией и незрелостью технологий. С производительностью - спорный вопрос, хотя с некоторыми оговорками готов согласиться...
В принципе я уже предлагал ответить на ряд вопросов на эту тему - я думаю моя позиция стала бы понятнее

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

2)Эксплуатация

2.1) Деплоймент изменений - каждое изменение в СП - это как минимум рестарт СП, возможно обновление всех клиентов. Зависит от фантазии разработчика.
При двузвенке - это просто прогрузка измененной процедуры. А если изменений несколько в день. Не пробовали? У вас наверное ежедневные билды и релиз раз в месяц? :)

2.2) Аудит системы, мониторинг производительности. В СУБД уже все есть ;)

2.3) Поиск нетривиальных ошибок в системе, да и тривиальных тоже. Врядли вы в своем СП реализуете, что-нибудь круче обычного SQL-Profiler. Хорошо если у вас есть хотябы БольшойПротокол работы СП.

2.4) Время безостановочной работы системы- как вы думаете, что проработает дольше глючный M$ SQL сервер или даже сто раз вылизанный самодельный СП?

2.5) Кто может поддерживать ваш СП? Только специально сертифицированные по вашему СП специалисты и разработчики. Первые и вторые это одни и те же люди? ;)

3) Зрелость
3.1) Хотели бы в 1980 году внедрять Оракыл у себя на предприятии? Когда еще не было РАДа, ОДБЦ и Оракыл падал и портил данные заказчиков:) Другими словами у меня глубокое ощущение, что идеи СП находятся сейчас примерно на той же стадии развития.

3.2) Поддержка со стороны поставщиков сред разработки.
Чтобы они не говорили об Архитектурах Систем Будущего, вытаскивать данные из СУБД в клиента умеют все и умеют хорошо.

3.3) Понимание со стороны разработчиков.
За годы клиент-серверной разработки выработались общепринятые приемы использования, с которыми знакомы все. В том числе люди готовые работать за 400 баксов. В области серверов приложений каждый изобретает свой велосипед. И долго будут еще изобретать, пока поставщики не договорятся до какого-то наименьшего общего знаменателя. Велосипеды приходится часто переделывать или вообще выкидывать, например когда поставщик скажет, что он ошибался и у него есть для вас лучшая технология.. Последнее время, кстати, они стали говорить это подозрительно часто.

3.4) Откуда берётся администратор для вашей системы?
Просто покупается на рынке и начинает делать свою работу? Покупается на рынке и учится с нуля? Какой вариант ваш?

3.5) Расскажите какой вы видите свою систему через 5 лет.
Наверное это вообще самый важный вопрос, когда рассуждаешь о зрелости технологии. Остальные вопросы, честно говоря, риторические - ответьте хотя бы на этот :)
...
Рейтинг: 0 / 0
16.10.2005, 13:58
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33326972
Анти_СП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Анти_СП
Гость
2 DrKonito
Эх, хороший пост написал, ждем ответов от VladiCh с большим нетерпением.
Правда боюсь, ответы будут такие же, как и ранее.

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

авторТигра от меня добивался конкретного примера использования объектов, вы же то меня тут другого добиваетесь :)
Ну так пример то будет али нет? А то Тигра лапы уже стер - столько раз ворос писал, а так ничего от вас и не добился. Некарашо!

авторВ "тигриной" терминологии, средний слой действительно представляет собой "толстый драйвер",..................
Тут вроде понятно - что-то передает туды-сюды данные. Точно непонятно, зачем именно так (почему вин-клиент не работает напрямую с БД?), но ладно, фиг с ним.

авторНа клиенте в случае WinForms для нее создается обертка для клиентской часть веб-сервиса, на сервере - для серверной. В случае WebForms вызов идет напрямую
Тут уже проблемы - зачем так, почему и что делается вообще...??? :)

авторНасчет того, как найти метод и вызвать его - зачем мне его искать, когда при выполнении запроса на выбор списка объектов, если например в списке разнотипные объекты, то на клиенте я получу их уже типизированными, с нужными методами , после того как вызову определенный метод будет вызван нужный веб-сервис и т.п.
Дык!!!!!!!!!!!!! Ёпрст!!!! Ну сколько можно.
Отмечено крсным болдом то, о чем разговор.
Как вы его вызываете то, метод ваш? В приложении - как? Если его на стадии разработки нет - как его можно вызвать?
Вас десятую страницу просят показать пример - вы упорно отказываетесь, каждый раз впадая в теорию ООП.

Переведу на русский язык, что у вас спрашивают, что вы отвечаете:
Вопрос: Скажите, как вы переключаете передачи в коробке передач вашей машины?
Ответ: Коробка передач - это такая штука, в которой есть шестеренки, валы и много чего другого. Когда шестеренки между обой взаимодействуют, от дигателя передается крутящий момент на колеса. Можно переключать передачи и передавать момент по разному.
Вопрос: Нет, это понятно, но мы проси вас рассказать, как именно вы именно в вашей машине переключаете передачи?
Ответ: Коробка передач - это такая штука...................
Вопрос (нервно, с топором руках): да все это знают, давно эти коробки зучены. Вы нам скажите, как вы физически переключаете передачи, с первой на вторую, дальше там.... в какой момент, как...
Ответ: Коробка передач - это такая штука...........................


Так расскажите или нет? Или прав Тигра - вы это еще не изучили?
...
Рейтинг: 0 / 0
16.10.2005, 18:20
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327097
архитектор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
архитектор
Участник
DrKonito Вобщем, это для меня "снижение квалификации кодеров" в случае объектных оберток бизнес-логики- типичный миф.
Я это видел своими глазами- не рекомендую. Решайте сами.

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

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

Т.е. разработку КС системы желательно вести след. образом:
1. Несколько квалифицированных человек пишут серверную часть + framework для работы с сервером
2. Для разработки GUI возможно привлечение "кодеров", аутсорсинг и т.п.

Теперь объясню, что я называю framework:
В зависимости от сложности и спецификации системы это может быть:
1. Просто WEB service, предоставляющий методы для доступа
2. Некий объектный mapper (обертка)
3. Более продвинутый СП, с кешированием результатов некоторых запросов, мат. вычислениями и т.п.

В любой системе со сроком жизни более 2 лет очень важно сохранить "стройность мысли" на серверной стороне - проектировать похожие вещи одинаково, придерживаться системы именований и т.п. Добиться этого можно, имея одного-двух человек в качестве core-team, и возможности привлечения неквалифицированных разработчиков для клиентской части.
Потому что найти одного "гуру" на замену можно, а вот найти быстро 5 вменяемых разработчиков - нереально.

В чем полностью согласен с DrCornito, что скорость "въезжания" в детали системы не зависит от того объектная она или нет. Если человек 3 года писал серверную часть на ХП, придумывал удобную ему систему именования процедур и т.п. - он сам в ней найдет все за секунду и никто не докажет ему, что объектный подход поможет ему в разработке системы - потому что действительно не поможет.

Сам я за объектный подход. В качестве примера можно взять Win32 API и VCL/.Net framework. Можно сделать одинаковый GUI на WinAPI и VCL? Конечно,
можно. Но найдите студента, который вам его сделает на WinAPI - их единицы (если вообще есть).
...
Рейтинг: 0 / 0
17.10.2005, 00:03
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327115
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
DrKonito3.5) Расскажите какой вы видите свою систему через 5 лет.
Наверное это вообще самый важный вопрос, когда рассуждаешь о зрелости технологии. Остальные вопросы, честно говоря, риторические - ответьте хотя бы на этот :)

Да ладно, я на все вопросы отвечу, мне не жалко, хотя приходится в выходные этим заниматься – на работе сейчас времени маловато стало…
Если с точки зрения бизнеса все пойдет нормально, то через 5 лет это будет внедряемая своими силами + возможно силами партнеров система + набор типовых решений для построения определенного типа корпоративных приложений. Какого типа – на 5 лет загадывать не буду. Сейчас планируется документооборот, CMS, CRM. Возможно, через 5 лет она будет более специализированной, возможно - наоборот.

DrKonitoОк, мне не жалко переформулирую:
1)Интеграция
С интеграцией у СП плохо не в том случае, когда СП скрывает от клиента подлинный источник данных - здесь у СП все хорошо. Плохо у них, когда стороннему приложению надо взаимодействовать с вашим СП. Расскажите, как в вашей системе решаются вопросы
1.1) построения отчетов

Пока что вручную на ASP.NET. Вообще планируем какое-нибудь готовое средство построения отчетов прикрутить, но какое - пока не определились.

DrKonito1.2) распределенных транзакций

Эта проблема решится с планируемым переходом на .NET 2.0, где проще реализуются возможности a-la COM+.

DrKonito1.3) пакетных заданий

Это вы как раз-таки про шедулер? Честно говоря здесь вообще проблемы не вижу.

DrKonitoЯ не говорю, что ни один из этих вопросов не решаем. Каждый из них решаем в том или ином виде. Вопрос в том, что ради этого вам придется писать кучу нетривиального кода, ради того, что в СУБД уже есть и этим надо просто пользоваться.

На моей прошлой работе ребята полгода собственный шедулер отлаживали (непростая тема оказывается), стандартные не подходили :) Да еще они хотели писать ОлеДб провайдер к своему СП :)

А вы зря смеетесь, и у нас в планах стоит задача написания провайдера данных. OLEDB, ODBC, ADO.NET – это непринципиально. В этом случае автоматически отпадает бОльшая часть проблем, связанных с интеграцией данных.

DrKonitoЯ понимаю, что это очень полезно и интересно с точки зрения чистого програмизма, но когда мне нужен результат с точки зрения заказчика, сами понимаете.

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

DrKonito2)Эксплуатация

2.1) Деплоймент изменений - каждое изменение в СП - это как минимум рестарт СП, возможно обновление всех клиентов. Зависит от фантазии разработчика.
При двузвенке - это просто прогрузка измененной процедуры. А если изменений несколько в день. Не пробовали? У вас наверное ежедневные билды и релиз раз в месяц? :)

Вы думаете, достаточно прогрузки измененной процедуры? А клиента в этом случае менять не надо? Ну если изменения косметические – то наверное не надо. А если меняется структура данных?

DrKonito2.2) Аудит системы, мониторинг производительности. В СУБД уже все есть ;)
Собственно, тут используются возможности ОС - Event log, Performance counters и т.п. Не вижу никаких проблем в реализации подобных возможностей.

DrKonito2.3) Поиск нетривиальных ошибок в системе, да и тривиальных тоже. Врядли вы в своем СП реализуете, что-нибудь круче обычного SQL-Profiler. Хорошо если у вас есть хотябы БольшойПротокол работы СП.

Ошибки ловятся довольно тривиальным образом, для этого не нужно профайлера. Если проблемы на уровне СУБД – дедлоки, падение производительности и т.п. – они ловятся тем же SQL-профайлером. Если на уровне приложения – для этого просто правильно пишется обработка ошибок с выводом в файл или event log. До сего времени проблем с отловом ошибок не было, хотя ситуации бывали всякие…

DrKonito2.4) Время безостановочной работы системы- как вы думаете, что проработает дольше глючный M$ SQL сервер или даже сто раз вылизанный самодельный СП?

См. пункт 3.1.

DrKonito2.5) Кто может поддерживать ваш СП? Только специально сертифицированные по вашему СП специалисты и разработчики. Первые и вторые это одни и те же люди? ;)

В настоящее время да.

DrKonito3) Зрелость
3.1) Хотели бы в 1980 году внедрять Оракыл у себя на предприятии? Когда еще не было РАДа, ОДБЦ и Оракыл падал и портил данные заказчиков:) Другими словами у меня глубокое ощущение, что идеи СП находятся сейчас примерно на той же стадии развития.

Все-таки в конечном итоге внедряется не Оракыл, а приложение, написанное на нем, которое точно также может падать и портить данные заказчиков. Вопрос только в квалификации разработчиков.

DrKonito3.4) Откуда берётся администратор для вашей системы?
Просто покупается на рынке и начинает делать свою работу? Покупается на рынке и учится с нуля? Какой вариант ваш?


Наш вариант – покупается на рынке и обучается. Администратора за 400 баксов покупать смысла никакого нет, поэтому процесс не будет столь драматичным, как Вы писали на тему обучения кодера :).

Прорезюмирую – я согласен с Вашим выводом о том, что СП – это на настоящий момент незрелая технология. Я отдаю себе отчет в том, что наш СП будет занимать довольно узкую нишу на рынке и не будет настолько универсальным средством, каким является промышленная СУБД. Но это не означает, что надо забить на него и ждать, пока кто-нибудь из больших компаний снизойдет до того, чтобы создать и достаточно продвинуть свой СП в массы.

авторДык!!!!!!!!!!!!! Ёпрст!!!! Ну сколько можно.
Отмечено крсным болдом то, о чем разговор.
Как вы его вызываете то, метод ваш? В приложении - как? Если его на стадии разработки нет - как его можно вызвать?
Вас десятую страницу просят показать пример - вы упорно отказываетесь, каждый раз впадая в теорию ООП.

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CollectionPager pager = new CollectionPager(
new Query("OrderBase", QueryOptions.Polymorph)
		.AddChildRelation(“OrderBase-OrderItem”)
.AddCriteria(new QueryCriteria("OrderBase", "UserId", "=", "@UserId"))
.AddCriteria(new QueryCriteria("OrderBase", "OrderType", "=", "@OrderType"))
		.SetSort("OrderDate", SortOrder.Descending)
.AddParam(“@UserId”, UserId)
.AddParam(“@OrderType”, OrderType)
.SetPaging( 1 , PageSize)));

IOrderCollection oc = pager.Load();
…..
По объекту типа IOrderCollection происходит binding к гриду в форме списка объектов.

Метод, вызываемый обработчиком событий формы, по которому изменяется стоимость товара в Order’е

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
protected virtual void ChangeItemPrice(IOrderBase order, Decimal price)
{
IOrderItem item = getCurrentItem();
Try
{
order.ChangeItemPrice(item.Id, price);
}
Catch  (Exception ex) { ExceptionManager.WriteToLog(ex); }
}
Как видно из примера, действие ChangeItemPrice выполняется методом объекта, доступ к которому идет через интерфейс IOrderBase. Метод, из которого выполняется это действие, определен в базовой форме списка заказов/счетов/заявок. От этой формы наследуются конкретные формы списков, в которых эту операцию переопределять или реализовывать заново уже не требуется.

Только пожалуйста, не говорите опять, что вам ничего не понятно или что я вам лекцию по ООП читаю… Понятнее по-моему уже объяснить трудно. Я вообще не пойму, чего вы от меня добиваетесь на пару с тигрой (или вы одно и то же лицо? :)) Чтобы я вам привел тут документацию к системе, чтобы ее для вас разжевал? И не надо тут про коробку передач издеваться. Какой вопрос – такой и ответ. Вы сами-то можете точно сформулировать, что вам надо? Или сами толком не знаете, что вам нужно?

-----------------------------------------------------
PS. Полностью согласен с последним постом от Архитектора.
...
Рейтинг: 0 / 0
17.10.2005, 02:02
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327240
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Архитектор
ГУЙ лучше пишется при помощи объектных средств- здесь я с вами полностью согласен. Главное чтобы это были стандартные средства поставщика. В этом суть моего поста- в том, что практически любая нестандартная объектная модель, особенно если она полностью скрывает СтандартнуюОписаннуюВКнижках, очень плохо совместима с дешевыми кодерами. Кодер не очень хорошо понимает и стандартные средства, а тут от него требуют разибраться в чем-то совсем космическом.

Про стройность мысли в серверной части я с вами полностью согласен. Но она достижима разными способами. Её (серверной части) объектность к этому отношению не имеет. Веб-сервисы например тоже не слишком объектны :)
...
Рейтинг: 0 / 0
17.10.2005, 08:51
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327278
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiCh DrKonito3.5) Расскажите какой вы видите свою систему через 5 лет.
Наверное это вообще самый важный вопрос, когда рассуждаешь о зрелости технологии. Остальные вопросы, честно говоря, риторические - ответьте хотя бы на этот :)
Если с точки зрения бизнеса все пойдет нормально, то через 5 лет это будет внедряемая своими силами + возможно силами партнеров система + набор типовых решений для построения определенного типа корпоративных приложений. Какого типа – на 5 лет загадывать не буду. Сейчас планируется документооборот, CMS, CRM. Возможно, через 5 лет она будет более специализированной, возможно - наоборот. ОК, кажется я начал понимать что у вас за система.
а) Вы собираетесь её продавать и ваш спонсор, судя по всему рассчитывает стать вторым Борисом Нуралиевым :). Он даже готов оплачивать собственный провайдер данных :). Это очень принципиальный момент. Возможно вам действительно не обойтись тогда без СП, а то исходники и правда могут скоммуниздить. Вот только технологические вопросы здесь ни при чем. Это всего-лишь бизнес-модель.

б) Система в очень ранней стадии разработки и восновном находится в стадии идей. Как захотите так и будет. Соответственно историями из опыта внедрения и эксплуатации вы врядли поделитесь.

в)Смена технологий вас пока не пугает пока, так как система маленькая и вы особо даже не запариваетесь над этим вопросом. Если чего перепишите и клиентов и сервера :)

VladiCh
Просто у нас разные задачи и соответственно разные результаты. Вы оцениваете общий подход применительно к своим частным задачам и делаете на основании этого общие выводы, хотя эти выводы применимы только к вашим задачам.
Мне кажется я всегда достаточно четко говорил, что все мои мнения - это чистое имхо, полученное в результате того чем я занимаюсь - разработкой и поддержкой самописных учетных систем. Не предназначенных на продажу. В условиях, когда ресурсов на упражнения в программизме нет.
Впрочем, ваши же слова можно отнести и к вам. С чего вы решили, что СП \объектные прослойки подходят всем?
...
Рейтинг: 0 / 0
17.10.2005, 09:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327323
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторОн даже готов оплачивать собственный провайдер данных :)

В написании ODBC-провайдера нет ничего волшебного и очень-супер-сложного.

Продолжайте, господа. Народ с интересом следит за веткой :)
...
Рейтинг: 0 / 0
17.10.2005, 09:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327325
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
VladiCh
>>1.1) построения отчетов
Пока что вручную на ASP.NET. Вообще планируем какое-нибудь готовое средство построения отчетов прикрутить, но какое - пока не определились.
Кстати интерсно вы банальную счет-фактуру на АСП.НЕТ делали? Или скажем ведомость выдачи З\п (с итогами на каждой странице)?
А по поводу внешнего генератора отчетов - вас ждет очередной раунд борьбы - мужайтесь.

VladiCh
DrKonito1.2) распределенных транзакций
Эта проблема решится с планируемым переходом на .NET 2.0, где проще реализуются возможности a-la COM+
Я спрашивал не о том как вы будете делать распр.транзакцию. Кстати до NET 2.0 это судя по всему пришлось бы делать еще один СП с поддержкой КОМ+. Впрочем при ваших ресурсах вы можете напрямую работать с MS DTC :) Меня скорее интересовала как ваша система будет принимать участие в РТ инициированной внешней системой?
Хотя вобщем-то до распределенных транзакций еще надо дорасти.

VladiCh DrKonito1.3) пакетных заданий
Это вы как раз-таки про шедулер? Честно говоря здесь вообще проблемы не вижу. В шедулере меня занимает вопрос о том как вы из батника будете пинать методы объектов вашего СП. Понятно, что способы есть, вопрос в том, что опять надо чего-то городить. А если надо пинать что-нибудь каждую секунду? Будете писать еще один апп-сервер с кэшированным коннектом к основному?

VladiChВы думаете, достаточно прогрузки измененной процедуры? А клиента в этом случае менять не надо? Ну если изменения косметические – то наверное не надо. А если меняется структура данных? В 90% случаев достаточно. Клиенты обновляеются только в случае появления нового функционала\исправления ошибок в них и только людьими, которым этот новый функционал нужен. Исправления в бизнес логике как правило вообще выкладываются незаметно для пользователей.

VladiCh DrKonito2.2) Аудит системы, мониторинг производительности. В СУБД уже все есть ;)
Собственно, тут используются возможности ОС - Event log, Performance counters и т.п. Не вижу никаких проблем в реализации подобных возможностей. Будете свои перфоманс каунтеры писать? Протоколировать каждый логин\логаут? ОК, признаю, в конце концов это вопрос ресурсов.[/quot]


VladiCh DrKonito
Хотели бы в 1980 году внедрять Оракыл у себя на предприятии? Когда еще не было РАДа, ОДБЦ и Оракыл падал и портил данные заказчиков:) Другими словами у меня глубокое ощущение, что идеи СП находятся сейчас примерно на той же стадии развития. Все-таки в конечном итоге внедряется не Оракыл, а приложение, написанное на нем, которое точно также может падать и портить данные заказчиков. Вопрос только в квалификации разработчиков. В 80м Оракыл еще сам падал, без помощи прикладных программистов. :) Вопрос даже не в оракле, а в том, что при молодости технологии легко можно привязаться к какому нибудь эээ ... Бтриву, а потом долго чесать репу на тему слезания с него. :)
...
Рейтинг: 0 / 0
17.10.2005, 09:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327406
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Урррааа, уррраааа, ответ получен!!!!!!!! :)

Правда чуда не случилось - в общем, оказалось то, что и ожидалось, но с другой немного стороны. Собственно, вот что:

VladiChКак видно из примера, действие ChangeItemPrice выполняется методом объекта, доступ к которому идет через интерфейс IOrderBase. Метод, из которого выполняется это действие, определен в базовой форме списка заказов/счетов/заявок. От этой формы наследуются конкретные формы списков, в которых эту операцию переопределять или реализовывать заново уже не требуется.
Отмечено главное.
Так вам все-таки нужно перелопачивать клиента, для того чтобы добавить еще один метод к объекту. Ничего автоматически не делается - руками только, независимо от того, ООП, не ООП - руками вы все делаете.

Тогда зачем эта вся шелуха, если вместо добавления каждый раз методов в базовый тип и форму и накручиванием для реализации работы всего этого странной прослойки, можно просто дернуть одну ХП в том месте, где это нужно - неужели это для вас труднее? Или, как я понимаю, вовремя не перестроились на жизнь и работу с СУБД и продолжаете все в стиле клиентского ООП?
Не мешало бы конечно посмотреть, что там внутри order.ChangeItemPrice(item.Id, price) - очень интересна дальнейшая реализация.

Я удивлен больше, чем ожидалось: если бы вы действительно начитывали список возможных методов в рантайме и потом дергали бы их через что-то типа DoMethod(MethodName, ParamList), то это конечно экзотический был бы вариант, но учитывая вашу приверженность к ООП, этот вариант входил бы в общую концепцию и в итоге представлял бы в принципе неплохое решение для действительно автоматизации системы .
Но вы сделали странное решение: вы в любом случае правите руками код на клиенте, сводя на нет все ваше ООП . Ну ГУИ не берем - тут не ООП конечно, а продвинутая система построения списков и м.б. еще чего-то на основе метаданных из БД (правда это есть у многих и к ООП не имеет отношения).
Получается, что мне в два раза легче как минимум (не знаю еще, что там внутри метода в базовом классе и на сервере, а то может и в 10 раз): для того, чтобы дернуть метод так сказать объекта, мне не нужно нигде ничего править, кроме как на той форме, где нужен вызов собственно сделать exec StpredProc .
Только не говорите, что я ничего не понял и т.п. - я тупо сравниваю количество времени и действий для того, чтобы исполнить какой-либо метод/ХП.

...............
Остальное в следующем посте прокомментирую

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 10:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327454
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Теперь ответ Архитектору.

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

авторИ вот здесь очень хорошо, чтобы сервер предоставлял некий ограничивающий framework разработчикам клиентской стороны.
Уж куда более лучший framework может быть, чем сама СУБД?
авторПри правильной организации этого framework можно не бояться, что человек испортит данные (логически естественно) на сервере, вызвав какую-нибудь ХП (написанную для внутреннего использования), не очень понимая, что она выполняет.
То есть, если кодер - дурак, то он каким-то образом ваш framework обойдет и не сможет вызвать нехороший метод, а ХП он вызовет бед проблем - так чтоли? (подсказка: а про права на ХП не слышали?)
Но то, что в процессе изучения для разработки системы кодеру для вызова ХП нужно просто ее вызвать - причем ту, каую сказали свыше - , то в вашем случае он еще должен выучить framework, помимо самого процесса разработки ГУИ.
Да, простой путь
авторТ.е. разработку КС системы желательно вести след. образом:
1. Несколько квалифицированных человек пишут серверную часть + framework для работы с сервером
2. Для разработки GUI возможно привлечение "кодеров", аутсорсинг и т.п.
Но если вы хотите простую и надежную систему, то лучше так:
1. Несколько квалифицированных человек пишут серверную часть и все - с СУБД умеют работать изначально многие "кодеры". Более того, вашу среверную часть могут использовать практически любые программы/системы/и т.д. без дополнительных действий, изучений и т.д.

авторТеперь объясню, что я называю framework:
В зависимости от сложности и спецификации системы это может быть:
1. Просто WEB service, предоставляющий методы для доступа
2. Некий объектный mapper (обертка)
3. Более продвинутый СП, с кешированием результатов некоторых запросов, мат. вычислениями и т.п.
В предложенном мной варианте этого ничего нет - почувствуйте разницу

авторВ чем полностью согласен с DrCornito, что скорость "въезжания" в детали системы не зависит от того объектная она или нет. Если человек 3 года писал серверную часть на ХП, придумывал удобную ему систему именования процедур и т.п. - он сам в ней найдет все за секунду и никто не докажет ему, что объектный подход поможет ему в разработке системы - потому что действительно не поможет.
А вот это правльно, полностью поддерживаю.

авторСам я за объектный подход. В качестве примера можно взять Win32 API и VCL/.Net framework. Можно сделать одинаковый GUI на WinAPI и VCL? Конечно,
можно. Но найдите студента, который вам его сделает на WinAPI - их единицы (если вообще есть).
За объектный подход в разработке ГУИ - да нет проблем.
Но переносить точно так же на БЛ и данные в РСУБД - извините, это разные вещи. FastObjects - вот там.... :))

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 10:56
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327470
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
VladiCh А вы зря смеетесь, и у нас в планах стоит задача написания провайдера данных. OLEDB, ODBC, ADO.NET – это непринципиально. В этом случае автоматически отпадает бОльшая часть проблем, связанных с интеграцией данных.
Да не зря - сначала сами придумали себе проблему, потом сами же думаете, как ее самим же решать :)

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 11:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33327606
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
2 VladiCh
Все забываю спросить.
Сколько у вас сейчас в БД объектов, какие предметные области покрываются системой, каков объем БД и какая нагрузка на нее - сколько клиентов и т.д.

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 11:43
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328052
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraУрррааа, уррраааа, ответ получен!!!!!!!! :)

Правда чуда не случилось - в общем, оказалось то, что и ожидалось, но с другой немного стороны. Собственно, вот что:

VladiChКак видно из примера, действие ChangeItemPrice выполняется методом объекта, доступ к которому идет через интерфейс IOrderBase. Метод, из которого выполняется это действие, определен в базовой форме списка заказов/счетов/заявок. От этой формы наследуются конкретные формы списков, в которых эту операцию переопределять или реализовывать заново уже не требуется.
Отмечено главное.
Так вам все-таки нужно перелопачивать клиента, для того чтобы добавить еще один метод к объекту. Ничего автоматически не делается - руками только, независимо от того, ООП, не ООП - руками вы все делаете.


Работа с метаданными как раз напрямую завязана на ООП.
Повторюсь еще раз. Все классы наследуются от базового класса Entity.
Для класса Entity определены операции Create, Edit, Delete, ChangePermissions.
Соответственно, все эти операции существуют для всех объектов и именно на этом принципе основано то, что мне не надо в общем случае для каждого объекта реализовывать это заново.

tygra
Тогда зачем эта вся шелуха, если вместо добавления каждый раз методов в базовый тип и форму и накручиванием для реализации работы всего этого странной прослойки, можно просто дернуть одну ХП в том месте, где это нужно - неужели это для вас труднее? Или, как я понимаю, вовремя не перестроились на жизнь и работу с СУБД и продолжаете все в стиле клиентского ООП?
Не мешало бы конечно посмотреть, что там внутри order.ChangeItemPrice(item.Id, price) - очень интересна дальнейшая реализация.


Неправильно понимаете. Опыта разработки на уровне СУБД у меня как раз побольше будет, чем в разработке GUI.
Насчет реализации метода ChangeItemPrice. Класс, к которому идет обращение через интерфейс IOrder, создается динамически и представляет из себя всего-навсего обертку для вызова веб-сервиса и возвращения результатов. С веб-сервисом ситуация аналогичная. Есть системный веб-сервис, через который выполняются общие запросы на выборку и изменение даных. И есть веб-сервисы для каждого класса - они точно также генерируются динамически. То есть при добавлении метода к классу мне нужно:
1. Описать его в метаданных.
2. Описать в интерфейсе.
3. Реализовать в соответствующем классе в промежуточном слое
4. Вызвать с клиента.

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

tygra
Я удивлен больше, чем ожидалось: если бы вы действительно начитывали список возможных методов в рантайме и потом дергали бы их через что-то типа DoMethod(MethodName, ParamList), то это конечно экзотический был бы вариант, но учитывая вашу приверженность к ООП, этот вариант входил бы в общую концепцию и в итоге представлял бы в принципе неплохое решение для действительно автоматизации системы .
Но вы сделали странное решение: вы в любом случае правите руками код на клиенте, сводя на нет все ваше ООП . Ну ГУИ не берем - тут не ООП конечно, а продвинутая система построения списков и м.б. еще чего-то на основе метаданных из БД (правда это есть у многих и к ООП не имеет отношения).
Получается, что мне в два раза легче как минимум (не знаю еще, что там внутри метода в базовом классе и на сервере, а то может и в 10 раз): для того, чтобы дернуть метод так сказать объекта, мне не нужно нигде ничего править, кроме как на той форме, где нужен вызов собственно сделать exec StpredProc .
Только не говорите, что я ничего не понял и т.п. - я тупо сравниваю количество времени и действий для того, чтобы исполнить какой-либо метод/ХП.


Есть возможность читать список методов и вызывать их динамически - но это-то как раз к ООП отношения не имеет, это скорее что-то типа Reflection в .NET. Я про такую возможность писал уже выше.
...
Рейтинг: 0 / 0
17.10.2005, 13:52
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328101
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Очень сложно - не в смысле понимания конечно, в смысле реализации.

Раз вам все-равно приходится все прописывать руками - не вижу никакого выигрыша.

Если у вас такой большой опыт в работе с СУБД, то вы давно бы сделали кое чего внутри СУБД по вызовам ХП и спокойно бы работали,
вместо того,
чтобы городить огромный огород по вызовам методов, их регистрации, вытаскивания, связывания и т.д., причем делать это все на клиенте или в среднем слое.
Чем вам не понравилась СУБД и ее возможности + реализация все того, что вы делаете, но более простыми способами в той же СУБД - не знаю. Но когда система переваливает за 500 таблиц становится понятно, что простота - залог здоровья :)

Я не к тому, что у кого-то круто, у кого-то нет.
Я к тому, что вы себе сами усложняете жизнь.

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

В общем, не завидую я вам в дальнейшем.

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 14:05
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328211
VladiCh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VladiCh
Участник
tygraВсе забываю спросить.
Сколько у вас сейчас в БД объектов, какие предметные области покрываются системой, каков объем БД и какая нагрузка на нее - сколько клиентов и т.д.
Та версия системы, про которую я сейчас пишу, пока находится в разработке .
Предыдущая версия описана здесь:
Ну что про нее можно сказать. Она собственно была чем-то вроде реализованного прототипа, на которой некоторые идеи обкатывались.
Сейчас посмотрел - 147 классов в БД, на уровне кода реализовано 83 класса (содержащих какую-то бизнес-логику). С системой работает порядка 20 пользователей. Объем около 2 Гб. Всего таблиц около 200, чуть меньше.
Количество записей в таблице объектов около 400000. То есть база небольшая и используется не очень активно, соответственно и загружена она слабо.

tygraЧем вам не понравилась СУБД и ее возможности + реализация все того, что вы делаете, но более простыми способами в той же СУБД - не знаю. Но когда система переваливает за 500 таблиц становится понятно, что простота - залог здоровья :)
Да мне нравится СУБД, просто почитайте внимательнее мой ответ и ответ DrKonito - он все правильно написал в принципе, за исключением того, что система уже вышла из стадии идей. Просто промежуточный слой в такой системе использовать практически _обязательно_, по совокупности нескольких причин. То есть для меня вопрос, использовать его или нет вообще не стоял, это было в условиях задачи. Стоял вопрос, как с использованием промежуточного слоя упростить жизнь программисту. И я стараюсь ее максимально упростить, создавая механизмы автоматической синхронизации данных и кода. Чем они хороши - пишутся только один раз.
Если бы это была только внутренняя система, да еще и без доступа снаружи, то я бы наверное не стал городить такой огород на указанных задачах - задачи такого объема можно проще решить используя 2 уровня. Просто ее планируется расширять и в будущем продавать. А здесь совершенно другие требования к системе. По поводу производительности - я уже писал, что есть возможности для ее оптимизации вручную.
Насчет сложности оптимизации, тормозов и т.п. - ну через годик можно будет к этому разговору вернуться - посмотрим :)
...
Рейтинг: 0 / 0
17.10.2005, 14:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328263
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Хорошо, вернемся через годик :)

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 14:54
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328739
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
Съездил на неделю в Норильск - а тут без меня такая дисскуссия развернулась - прямо бои паскалистов и сишников:)

Попробую высказать пару мыслей в защиту объектно-ориентированного подхода к построению информационных систем. Все нижесказанное есть выстраданное ИМХО:)

1. ООП в бизнес-приложениях - это модель приложения в понятиях "реального мира", тот самый уровень абстракции, который позволяет работать с информационной системой не только программисту. Если система небольшая, если программист напрямую общается с заказчиком на уровне "вы скажите, че надо - я слабаю), то ООП - не нужное усложнение. Если же у вас существуют такие цепочки, как "заказчик-бизнес аналитик-программисты" или "заказчик-бизнес аналитик--архитектор-программисты", то объектно-ориентированный подход дает огромное преимущество - все (ну, может, кроме заказчика) начинают мыслить на уровне объектов. UML становится языком технических заданий, понятным всем. Появляется формальная процедура внесения изменений в информационную систему. Работа в команде становится более эффективной - архитектор проектирует классы и поручает реализацию конкретных интерфейсов разным программистам. При таком подходе поддерживать и развивать систему становится гораздо проще, плюс гораздо больше шансов, что архитектура информационной системы остаенется "правильной" в течение всего жизненного цикла системы.
2. ООП в бизнес-приложениях никак не связан с наличием сервера приложений. Просто большинство серверов приложений предполагают работу с бизнес-объектами, поэтому они стали синонимом объектно-ориентированного подхода к разработке бизнес-приложений. Более того, объектный подход может быть никак не связан с техническими возможностями среды разработки - возьмите бумажку (или UML-редактор:), перечислите свои БИЗНЕС-объекты, их свойства, методы, связи, workflow - вот вам и описание системы. Используйте это описание на всех этапах разработки и сопровождения, постоянно актуализируйте его, вот вам и объектный подход. Однако гораздо эффективнее, когда объектная модель и код приложения являются одним целым.
3. Повторю, для тех, кто не читал мои посты в начале ветки. То, что мы делаем у себя - создание "классов-оберток" - как раз и позволяет придать объектный вид классическому 2х-слойному бизнес-приложению. Эти классы создаются автоматически из метаданных. Помимо основной роли такие классы-обертки берут на себя ряд дополнительных функций:
- автоматическая генерация интерфейса на основе "визуализаций" данного класса (визуализации тоже наследуются, перекрываются и т.п.)
- "раннее" оповещение об изменениях - вы узнаете об изменениях в БД по факту, а не по "рефрешу"
- свой механизм транзакций - все изменения вначале записываются в некий пул изменений, измененные объекты лочатся, затем по коммиту все изменения проводятся в БД.
- свой механизм кеширования данных. На клиента данные качаются "порциями", зависящими от размера кеша.
- объекты могут служить источником данных для нормальных визуализационных классов .NET
- поддержка разных версий одного класса в одной системе
- механизм имперсонификации и своя система разграничения прав
- workflow на основе "матрицы состояний" класса
- многое другое

Сейчас классы-обертки работают на клиенте, или, правильнее сказать, на той стороне, где строится интерфейс. Пока, на этапе рефакторинга нашей информационной системы, основная функция классов - автоматическое построение интерфейса. Бизнес-логика большей частью осталась в хранимых процедурах, частью генерится автоматически на основе табличного описания алгоритмов хоз.операций (проводок). Cложные алгоритмы находятся в хранимых процедурах. При необходимости часть бизнес-логики можно будет перенести в .NET и запускать на некоем сервере приложений, однако пока такой необходимости не стоит.

Если кого интересует более подробное описание библиотеки - см. мои посты выше, я приаттачивал файл с описанием.
...
Рейтинг: 0 / 0
17.10.2005, 17:12
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328926
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
авторООП в бизнес-приложениях - это модель приложения в понятиях "реального мира", тот самый уровень абстракции, который позволяет работать с информационной системой не только программисту
Неужели чтобы понять вашу систему кому-то кроме программиста, вам нужно ООП? Или ему нужно учить ООП? Или кому? :))
авторЕсли система небольшая, если программист напрямую общается с заказчиком на уровне "вы скажите, че надо - я слабаю), то ООП - не нужное усложнение.
Конечно, такой программист ООП то не знает - лабать много ума не надо :))
авторЕсли же у вас существуют такие цепочки, как "заказчик-бизнес аналитик-программисты" или "заказчик-бизнес аналитик--архитектор-программисты", то объектно-ориентированный подход дает огромное преимущество - все (ну, может, кроме заказчика) начинают мыслить на уровне объектов.
Вы что, всех этих людей ООПу учите? Прсто насильно или деньги еще берете за это? А кто устраивается аналитиком - экзамены по ООП сдает?
авторUML становится языком технических заданий, понятным всем. Появляется формальная процедура внесения изменений в информационную систему. Работа в команде становится более эффективной - архитектор проектирует классы и поручает реализацию конкретных интерфейсов разным программистам. При таком подходе поддерживать и развивать систему становится гораздо проще, плюс гораздо больше шансов, что архитектура информационной системы остаенется "правильной" в течение всего жизненного цикла системы.
То есть простым языком, вы почему то без ООП в системе не можете построить процесс разработки? Вы может это, того, не тех виноватых нашли - может других книг почитать, не ООП, а по организации процессов на предприятии?
Да, хороша у вас жизнь............. :)
авторПомимо основной роли такие классы-обертки берут на себя ряд дополнительных функций:
Рассмотрим :)
автор- автоматическая генерация интерфейса на основе "визуализаций" данного класса (визуализации тоже наследуются, перекрываются и т.п.)
Тут ООП ни при чем - но может получиться даже хуже, чем просто руками. Смотря что подразумевается под автоматическая генерация
автор- "раннее" оповещение об изменениях - вы узнаете об изменениях в БД по факту, а не по "рефрешу"
При чем тут обертки, ООП? Кому надо - тот и так делает.
автор- свой механизм транзакций - все изменения вначале записываются в некий пул изменений, измененные объекты лочатся, затем по коммиту все изменения проводятся в БД.
Неужели вы сделали это лучше, чем в MS SQL?!!! Вах!
автор- свой механизм кеширования данных. На клиента данные качаются "порциями", зависящими от размера кеша.
Зачем?
автор- объекты могут служить источником данных для нормальных визуализационных классов .NET
Бррррр..
автор- поддержка разных версий одного класса в одной системе
Круто - в одной системе по-разному работать с одним объектом! Это уже в достоинство возвели? Я думал, это недостаток - когда логика на клиенте, а клиенты разные (забыли обновить) :)
автор- механизм имперсонификации и своя система разграничения прав
У кого ж ее нет?
=======================

Это так, ответный выстрел.

И чем только люди не занимаются, лишь бы время убить да систему посложнее сделать - чтобы никто другой не смог с ней работать, ну и оптимизация еще - через небольшое время все умрет и можно вторую версию делать, опять же работа надолго обеспечена :))

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 18:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33328937
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Хотя конечно нужно разделять, зачем делается система.

Одно дело - для себя, чтоб работало .
Другое дело - для дяди, тираж, чтоб настраивалось , а работа уже десятое дело - проблема покупателей.

Для дяди в тираж я наверное тоже бы сделал что-нибудь настраиваемое - чтобы потом при продажи быстренько настроить и отвалить. А потом деньги за поддержку, оптимизацию...... Деньги, деньги, деньги за всё.......

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

Вот такие пироги.... жеваные

-- Tygra's --
...
Рейтинг: 0 / 0
17.10.2005, 18:17
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329132
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
tygra
Неужели чтобы понять вашу систему кому-то кроме программиста, вам нужно ООП? Или ему нужно учить ООП? Или кому? :))
...
Вы что, всех этих людей ООПу учите? Прсто насильно или деньги еще берете за это? А кто устраивается аналитиком - экзамены по ООП сдает?

Наверное ООП неправильный термин. Речь идет об объектно-ориентированном подходе. Хорошие бизнес-аналитики и архитекторы им владеют. UML - язык для создания объектных моделей. Его, ИМХО, надо знать наравне с SQL. А учим мы методом "веревки и палки":)
tygra
То есть простым языком, вы почему то без ООП в системе не можете построить процесс разработки? Вы может это, того, не тех виноватых нашли - может других книг почитать, не ООП, а по организации процессов на предприятии?
Да, хороша у вас жизнь............. :)

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

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

Раннее оповещение - это один из аналогов "событий" в объектном понимании и очено хорошо ложится в логику объектного подхода. То есть, если у вас в кеше лежат инстанции объектов, а кто-то их изменил в БД, вы получите оповещения от этих инстанций, а объекты актуализируются.
tygra
автор- свой механизм транзакций - все изменения вначале записываются в некий пул изменений, измененные объекты лочатся, затем по коммиту все изменения проводятся в БД.
Неужели вы сделали это лучше, чем в MS SQL?!!! Вах!

SQL транзакции не предполагают "протяженности во времени", они должны быть настолько короткими, насколько возможно. Представьте себе, что вы, открыв форму, посылаете серверу BEGIN TRAN, потом что-то там делаете в БД, а потом при нажатии на OK посылаете COMMIT или при нажатии на CANCEL посылаете ROLLBACK. Не буду объяснять недостатков подобного подхода.
У нас есть свой механизм транзакций. Для изменения объектов надо начать такую транзакцию. Упрощенно говоря - при изменении объектов изменения накапливаются, измененные объекты "лочатся" (нашими средствами), при коммите такой транзакции все накопившиеся изменения "накатываются" на SQL сервер, при отмене транзакции - просто объекты возвращаются в состояние "до начала транзакции". До закрытия транзакции есть возможность делать UNDO.
tygra
автор- свой механизм кеширования данных. На клиента данные качаются "порциями", зависящими от размера кеша.
Зачем?

Представьте себе, что у вас в таблице 100 млн. записей. Вы хотите работать с этими записями как с коллекцией инстанций объектов. Или (не подумав) создаете Grid и заполняете его записями из этой таблицы, забыв про фильтр. У нас это все возможно, т.к. работа идет через кэш и сервер выдает на клиента только TOP N записей.
tygra
автор- объекты могут служить источником данных для нормальных визуализационных классов .NET
Бррррр..

Не понял? Что вам тут не понравилось? Объекты имлементируют все интерфейсы, которые нужды для работы в качестве источников данных. Что тут такого?
tygra
автор- поддержка разных версий одного класса в одной системе
Круто - в одной системе по-разному работать с одним объектом! Это уже в достоинство возвели? Я думал, это недостаток - когда логика на клиенте, а клиенты разные (забыли обновить) :)

Вообще-то это версионность - это свойство всех промышленных информационных систем. Представьте себе, что у системы и у объектов, ее составляющих есть номер версии, и вся история изменений накапливается в системе. Изменения можно распространять на работающей системе, потом надо лишь переключить текущий номер версии - и вуаля:) Там есть еще много фишек, например для коллективной разработки - check in, check out и т.п.
tygra
автор- механизм имперсонификации и своя система разграничения прав
У кого ж ее нет?

Завидно?:)
...
Рейтинг: 0 / 0
17.10.2005, 20:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329449
архитектор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
архитектор
Участник
tygraВ нашей системе как раз таки клиентскую часть писать нет проблем - есть набор стандартных форм, от которых вы наследуетесь, в самом сложном случае прописываете там 3 (три) хранимых процедуры и контролы/колонки списка. Все. Добавление комплекта форм к какой-то таблице занимает не более получаса времени.
А вот как раз вся основная работа проводится на сервере БД.
Так что.... Может в вашем королевстве не так что-то? :))

Да, не так :) Например, у нас есть формы, отображающие динамически изменяющиеся графики. Здесь на клиентской стороне начинаются потоки, синхронизация и все, что с этим связано. И при неумелом использовании всего этого возникают трудно отыскиваемые проблемы и вообще корявый GUI. И часто люди, хорошо разбирающиеся в такого вида программировании вообще не видели СУБД в глаза, зато отлично знают, как писать ОО программы на С++.

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

Мы с вами работаем на разных рынках - я на тиражируемых продуктах, вы, скорее всего, создаете продукт для "внутреннего использования".
Представьте себе такой случай: начальство радостно объявляет, что уже почти продали новую версию продукта, которая должна выйти через N месяцев. При этом выясняется, что покупатель выставил ряд требований к системе (новых возможностей). Вы делаете дизайн, прикидываете время и выясняется, что ваша команда из 3-х человек, обычно сопровождающая проект, просто физически не укладывается в заданные сроки. Вы идете к начальству - вам в ответ дают возможность привлечь несколько человек с других проектов, которые с СУБД никогда не работали или взять несколько людей с аутсорсинга (об их квалификации вы можете только догадываться по резюме, которое всегда блещет достижениями и громкими фразами).

Вот в таких случаях и помогает какая-либо обертка/СП или что-то подобное. Людей, знающих С++/С#/Java найти несложно - это скорее всего любой разработчик в вашей компании. Все обычно умеют пользоваться Code complete в редакторе VS.Net и могут прочитать описание метода и параметров, которые студия показывает когда набираешь код.
Людей, работавших с СУБД - в разы меньше. Обучать их работать с Enterprise manager, системе наименования ХП, гда пойти и почитать документацию по описанию ХП и ее параметрам - дольше. И стоят они дороже.

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

tygraТо есть, если кодер - дурак, то он каким-то образом ваш framework обойдет и не сможет вызвать нехороший метод, а ХП он вызовет бед проблем - так чтоли? (подсказка: а про права на ХП не слышали?)

А есть возможность средствами СУБД запретить вызывать ХП напрямую из клиента, но при этом оставить возможность вызвать ее из другой ХП, которая напрямую этим клиентов вызывается ( имеется в виду аналог protected/private метода в ООП)?

tygraТо есть простым языком, вы почему то без ООП в системе не можете построить процесс разработки? Вы может это, того, не тех виноватых нашли - может других книг почитать, не ООП, а по организации процессов на предприятии? Да, хороша у вас жизнь............. :)

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

Никто не заставляет Вас использовать ООП. Если у Вас уже есть готовая система, которую вы дописываете и сопровождаете - конечно, переводить ее на другой язык, писать обертки - это чистая трата денег.
Вы всегда найдете программиста, который напишет GUI на MFC быстрее, чем вы на Delphi, потому что у него уже есть 350 готовых форм, которые он знает наизусть и все повторяющиеся куски обернуты в макросы. При этом он вам будет доказывать, что пользоваться оберткой WinAPI на Pascal с различными багами и ограничениями от Borland нелепо и незачем. Кода у него получается меньше, а все баги он уже исправил. Это, по-вашему, служит причиной, чтобы отказаться от Delphi и всем сесть на MFC?

Если вы не видите для себя выгоды в использовании ООП - ради бога, не используйте. Люди здесь рассказывают об используемых технологиях не потому что хотят Вам доказать, что их система круче и быстрее. Просто кто-то нашел удобный для себя способ выражения мыслей, создания модели и обсуждения ее с аналитиками и другими разработчиками. Если вы не представляете/не хотите представлять как можно модель системы выразить в объектах через свойства и методы - это не значит, что остальные тоже этого не могут и не должны делать.

Кстати, мне кажется, что наличие на рынке большого количества UML редакторов и case-средств, где и используются принципы ООП, является доказательством того, что у ООП есть применение. И моделируют там не GUI, а как раз объекты системы и бизнес-логику.
...
Рейтинг: 0 / 0
18.10.2005, 09:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329501
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
ОК, Дмитрий, кажется я начал чего-то понимать. У вас бизнес-логика изначально была в СУБД. Особенно после того, как вы убедились, что апп-сервера вам производительности не прибавили :). Теперь она "размазана" между СУБД и в данный момент "толстым клиентом". При этом вы присматриваетесь не будет ли красивее "размазать" еще чего-нибудь на выделенный СП?


Дмитрий Сорокин
То, что мы делаем у себя - создание "классов-оберток"
- как раз и позволяет придать объектный вид классическому 2х-слойному бизнес-приложению.
Cекьюрити, триггера, транзакции и воркфлоу уже в толстом клиенте? Не слабая оберточка. Это вы называете объектным видом классического двухзвенного приложения? :) Вы пишете очередной ОРМ - называйте вещи своими именами.

Вы, кстати, тоже хотите стать Борисом Нуралиевым? Или вы считаете, что потратив ресурсы на создание фирменного ОРМ-а вы дадите конкурентное преимущество своему предприятию? Или что производительность труда вверенных вам подразделений при использовании ОРМ-а возрастет многократно?
Вы кстати считали сколько вы уже потратили на ОРМ? В килобаксах? А сколько еще потратите? Лучше бы готовый взяли, чесслово.

Аргументы про красивее и правильнее-не приводите. На вкус и цвет сами знаете.

Дмитрий Сорокин
В принципе ничто не запрещает использовать эти интерфейсные объекты, например, при написании скриптов на каком нибудь vbscript или С# с последующим запуском локально или на некоем дот-нетовском scripting host. Типа - вот вам и сервер приложений...
:) А что вам мешает просто вызывать ХП из уже существующего scripting host, а не из "некого dot-netовского" (afaik еще не вышедшего) ?

Дмитрий Сорокин
Хотя все это ИМХО, и, возможно, мы изобретаем велосипед:)
В начале 90-х в каждом уважающем себя отделе АСУ(особенно в тех в которых программистов было много, а работы мало ;) ) было принято писать dbase-совместимую СУБД. С массой преимуществ перед стандартной естественно :) Имхо сейчас та же фигня, только все теперь пишут свой ОРМ. Люди не меняются :)
...
Рейтинг: 0 / 0
18.10.2005, 09:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329632
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Дмитрий Сорокин Наверное ООП неправильный термин. Речь идет об объектно-ориентированном подходе. Хорошие бизнес-аналитики и архитекторы им владеют.

Наверное... Тока в этом топике решь шла о ООП реализации бизнес-логики, а не об ООМ (объектно-ориентированном моделирование), про которое Вы нам тут расказываете. Хороший бизнес-аналитик и архитектор - это тот, у кого спроектированная система спроектирована так, что ее легко понять, внедрять и сопровождать. Ну, и она должна как минимум работать. И из этого совсем не следует, что обязательно должно использоваться ООМ!

Дмитрий СорокинНу-ка, ну-ка, tygra, поделитесь сокровенными знаниями о процессах разработки. И об организации процессов на предприятиях. И зачем нам отказываться от объектного подхода? Только потому, что вам это не нравиться?

Никто Вас ни от чего не заставляет отказываться. Только не надо продвигать ООМ подход как панацею. Существуют и другие методики проектирования и внедрения приложений. На счет поделиться... Что Вас конкретно интересует?!

Дмитрий СорокинSQL транзакции не предполагают "протяженности во времени", они должны быть настолько короткими, насколько возможно. Представьте себе, что вы, открыв форму, посылаете серверу BEGIN TRAN, потом что-то там делаете в БД, а потом при нажатии на OK посылаете COMMIT или при нажатии на CANCEL посылаете ROLLBACK. Не буду объяснять недостатков подобного подхода.

Я так думаю, что в каждой системе, есть что-то подобное. Я это называю "блокировками" на уровне бизнес-логики. Только вот опять это все реализовано у меня без каких-либо объектных оберток - что более прозрачно и понятно!

Дмитрий СорокинПредставьте себе, что у вас в таблице 100 млн. записей. Вы хотите работать с этими записями как с коллекцией инстанций объектов. Или (не подумав) создаете Grid и заполняете его записями из этой таблицы, забыв про фильтр. У нас это все возможно, т.к. работа идет через кэш и сервер выдает на клиента только TOP N записей.

Опять мимо... постраничный Вывод лекго реализуется средствами СУБД без каких-либо "объектных наворотов". Вспоминается реклама Dew... ;)

Дмитрий СорокинВообще-то это версионность - это свойство всех промышленных информационных систем. Представьте себе, что у системы и у объектов, ее составляющих есть номер версии, и вся история изменений накапливается в системе. Изменения можно распространять на работающей системе, потом надо лишь переключить текущий номер версии - и вуаля:) Там есть еще много фишек, например для коллективной разработки - check in, check out и т.п.

Я Вас умоляю... Для поддержки версионности как Вы крассиво выразились "свойства всех промышленных информационных систем" эта система не обязательно должна быть спроектирована по ООМ и использовать ООП бизнес-логику.

АрхитекторПредставьте себе такой случай: начальство радостно объявляет, что уже почти продали новую версию продукта, которая должна выйти через N месяцев. При этом выясняется, что покупатель...

Хм... Интересный подход... Прибыльность в угоду качеству... Чтож, такое возможно...

АрхитекторА есть возможность средствами СУБД запретить вызывать ХП напрямую из клиента, но при этом оставить возможность вызвать ее из другой ХП, которая напрямую этим клиентов вызывается ( имеется в виду аналог protected/private метода в ООП)?

Вы серьезно об этом не знаете или пошутили?! Есть такая возможность.
...
Рейтинг: 0 / 0
18.10.2005, 10:23
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329645
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
DrKonitoОК, Дмитрий, кажется я начал чего-то понимать. У вас бизнес-логика изначально была в СУБД. Особенно после того, как вы убедились, что апп-сервера вам производительности не прибавили :). Теперь она "размазана" между СУБД и в данный момент "толстым клиентом". При этом вы присматриваетесь не будет ли красивее "размазать" еще чего-нибудь на выделенный СП?

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

Все не так ужасно.
1. Секьюрити - действительно проверяется на клиенте. На сервере БД у всех одни права (имперсонификация). Но естественно вся информация о правах хранится в БД, а на клиенте лишь проверяются права доступа пользователя к свойствам и методам объекта.
2. Триггера лежат на сервере:) На клиенте - никакой бизнес-логики.
3. Транзакции - я бы скорее назвал их пакетами изменений - действительно открываются на клиенте. Но это очень легкая и логичная система.
4. Воркфлоу - отрабатывается на клиенте. А где же ему еще отрабатываться? Но все алгоритмы лежат в метаданных на сервере.
На самом деле тут все очень логично - классам-оберткам передан ряд утилитарных функций, которые легко вписываются в объектную модель.
DrKonito
Вы, кстати, тоже хотите стать Борисом Нуралиевым? Или вы считаете, что потратив ресурсы на создание фирменного ОРМ-а вы дадите конкурентное преимущество своему предприятию? Или что производительность труда вверенных вам подразделений при использовании ОРМ-а возрастет многократно?
Вы кстати считали сколько вы уже потратили на ОРМ? В килобаксах? А сколько еще потратите? Лучше бы готовый взяли, чесслово.

Аргументы про красивее и правильнее-не приводите. На вкус и цвет сами знаете.

А как бы вы предложили дальше поддерживать развивать систему, установленную на 30 заводах (около 3000 рабочих мест, суммарно - почти 1 ТБ накопленных данных), живущую уже 10 лет, постоянно дописываемую, с чистой клиент-серверной архитектурой (тонкий клиент), с миллионами строчек кода, тысячами таблиц и хранимых процедур, с модулями написаннами и на Delphi (от 3.0 до 5.0) и на Access (от 2.0 до 2000) и на VB и на С# и на Excel? Где каждый программист норовил написать собственный ОРМ или на крайний случай хотя бы бы свою библиотеку?
С моей точки зрения подобная "объектизация" - единственный вариант рефакторинга сложной системы, имеющий шанс на успех. При таком подходе нет необходимости переписывать все заново - в теории надо лишь описать имеющиеся бизнес-объекты и бизнес-превила в метаданных и получить работающую систему (а заодно и бизнес-модель системы)
...
Рейтинг: 0 / 0
18.10.2005, 10:29
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33329723
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
АрхитекторИ часто люди, хорошо разбирающиеся в такого вида программировании вообще не видели СУБД в глаза, зато отлично знают, как писать ОО программы на С++.
Я уж молчал, но за меня сказали Я в своей жизни много видел писателей звеньев, своих драйверов доступа к СУБД, гридов, и прочего ... и всегда и везде это были Сишники, сто процентно уверенные, что легче написать самому, чем разбираться с чужим ... особенно с непонятным каким то SQL. У нас в дочерней конторе тоже такие есть, причем на очень крупном проекте - свои классы, свой драйвер доступа к Oracle, свой грид на его базе, даже свой аналитический отчетник - уххх, без слез смотреть нельзя, как народ умудряется все свое основное время вместо того, чтобы проектировать бизнес-логику с багами и доработками в своих "движках" сражается. За год, что они у нас работают, можно сказать они почти на 50% сделали таки чего то иногда работающее. Мы же с февраля успели на связке ASA-PB-FR накатать, отработать и запустить в эксплуатацию 2 полноценных немаленьких проекта (один как распределенный на базе оффлайн репликации с кол-вом узлов), основанных на базе нашей платформы, представляющей из себя схему таблиц и ХП в БД, классы и формы в PB и COM-сервер на базе FR. Причем их сопровождение занимает минимум времени, а дальнейшее развитие нашей платформы в новых проектах элементарно портируется на существующие проекты через систему контроля версий скриптов БД, распостранение базовых иерархических библиотек PB для клиентских частей и новых версий COM-сервера отчетника.

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

АрхитекторЛюдей, работавших с СУБД - в разы меньше. Обучать их работать с Enterprise manager, системе наименования ХП, гда пойти и почитать документацию по описанию ХП и ее параметрам - дольше. И стоят они дороже.
Странно, не знал, что есть еще кодеры, не умеющие писать SELECT * FROM Table/StoredProc(). Не путайте проектировщика БД и кодера, от которого требуется знание стандартного ANSI SQL. Никто кодеру и не позволит писать сложные запросы или же тяжелые ХП - даже если он и напишет, все это будет дано на приемку и тестирование проектировщику БД.

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

АрхитекторА есть возможность средствами СУБД запретить вызывать ХП напрямую из клиента, но при этом оставить возможность вызвать ее из другой ХП, которая напрямую этим клиентов вызывается ( имеется в виду аналог protected/private метода в ООП)?
Не знание элементарных основ РСУБД не дает права рассуждать о недостатках РСУБД и преимуществах ООП, не правда ли ? Забавно, что о недостатках ООП обычно начинают рассказывать, сделав (или еще чаще не сделав) реально работающие проекты, когда эйфория от легкости проектирования на ООП схемы данных малость проходит и настают тяжелые будни расширения функциональности проекта, отловки багов в самописных движках, прикручивания стандартных отчетников, борьбой с проседанием РСУБД и собственного приложения на больших нагрузках и прочих, прочих радостей жизни, коими не обделены все разработчики своих ООП расширений на базе РСУБД.

АрхитекторЕсли вы не видите для себя выгоды в использовании ООП - ради бога, не используйте. Люди здесь рассказывают об используемых технологиях не потому что хотят Вам доказать, что их система круче и быстрее. Просто кто-то нашел удобный для себя способ выражения мыслей, создания модели и обсуждения ее с аналитиками и другими разработчиками. Если вы не представляете/не хотите представлять как можно модель системы выразить в объектах через свойства и методы - это не значит, что остальные тоже этого не могут и не должны делать.
Полностью согласен, каждая технология имеет права на жизнь. Но с одним условием - нечего тогда рассказывать, что ООП выгодней, чем классическое приложение клиент-сервер, особенно когда 90% из рассказывающих это, на моей практике, как минимум сами не делали больших рабочих проектов на этой связке и не могут похвастаться глубокими познаниями какого либо РСУБД.
...
Рейтинг: 0 / 0
18.10.2005, 10:48
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33330011
ВМоисеев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВМоисеев
Участник
Коллеги,
можно ли вернуться и ответам на исходный вопрос.

Если кого-то не интересуют многозвенки, как их строить - а все задачи на сервер данных - флаг им в руки.
Меня же интересует именно вопрос многозвенок, серверов приложений и распределенных вычислений.
Можно ли продолжить в этом направлении?

С уважением, Владимир.
...
Рейтинг: 0 / 0
18.10.2005, 12:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33330072
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Если мы хотим обрабатывать данные, поступающие с компьютеризованного промышленного оборудования, то дополнительно звено просто необходимо, это OPC-сервер. Здесь мы столкнемся и с распределенностью вычислений, и с вопросами сохранения производительности(время реакции), да и с базами данных тоже. Ну, а поскольку оборудования может быть много и оно рассредоточено, то без звеньев никуда. Считаю,что нужно просто решать конкретную задачу,максимально просто и надежно. Но в данном случае без доп.звеньев обойтись проблематично.
...
Рейтинг: 0 / 0
18.10.2005, 12:18
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33330264
Фотография 1024
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
1024
Участник
"ВМоисеев" <nospam@sql.ru>; wrote in message news:1978363@sql.ru...
Коллеги,
можно ли вернуться и ответам на исходный вопрос.

Если кого-то не интересуют многозвенки, как их строить - а все задачи на
сервер данных - флаг им в руки.
Меня же интересует именно вопрос многозвенок, серверов приложений и
распределенных вычислений.
Можно ли продолжить в этом направлении?

С уважением, Владимир.
Тема Ответить

================================

а исходный вопрос был не "многозвенка" т.е. не

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

а "Создание сервера приложений" т.е. вынос логики работы системы (а не
функции транспортировки или конвертации) с сервера БД или клиента в
отдельное звено/сервер


Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
18.10.2005, 13:11
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33331108
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Дмитрий Сорокин
А как бы вы предложили дальше поддерживать развивать систему, установленную на 30 заводах (около 3000 рабочих мест, суммарно - почти 1 ТБ накопленных данных), живущую уже 10 лет, постоянно дописываемую, с чистой клиент-серверной архитектурой (тонкий клиент), с миллионами строчек кода, тысячами таблиц и хранимых процедур, с модулями написаннами и на Delphi (от 3.0 до 5.0) и на Access (от 2.0 до 2000) и на VB и на С# и на Excel? Где каждый программист норовил написать собственный ОРМ или на крайний случай хотя бы бы свою библиотеку?
С моей точки зрения подобная "объектизация" - единственный вариант рефакторинга сложной системы, имеющий шанс на успех. При таком подходе нет необходимости переписывать все заново - в теории надо лишь описать имеющиеся бизнес-объекты и бизнес-превила в метаданных и получить работающую систему (а заодно и бизнес-модель системы)
Не совсем понял. У вас физически одна СУБД с 3000 клиентов написанных на целом зоопарке технологий?
Или это несколько однотипных СУБД с примерно 100 клиентами на завод и возможно некой центральной СУБД куда стекается информация для консолидации?

В любом случае вопросы такого масштаба как у вас, имхо не решаются на технологическом уровне. Расширяемость систем такого масштаба решается не на уровне объектной обертки. Это скорее вопрос к аналитикам, к правильности их видения места системы в контексте предприятия и стратегии её развития в терминах бизнеса. Эти вопросы никак не связаны с технологиями реализации системы.
Мне очень слабо верится, что с появлением объектной обертки начнется "самоорганизация" системы "снизу", скорее это закочится если не хаосом, то очень серьезным усложнением и без того сложного.

Если говорить чисто техически, то делая объектную обертку вы сразу попадаете на необходимость одномоментной замены десятка разновидностей клиентских приложений - что есть процесс болезненный и трудоёмкий. Мне достаточно тяжело представить себе интеграцию клиента на Ацессе 2.0 с сервером приложений\либо даже просто с ин-процесс КОМ сервером, написанным на шарпе.

На вашем месте я бы шел эволюционным путем, вместо революционных переделок. Рефакторил бы СУБД. Вложился в документацию. Занялся бы системой обучения новичков. Выстроил бы процесс управления конфигурацией. Параллельно с этим я бы попытался постепенно уменьшить количество особей в зоопарке клиентских приложений, начиная с наиболее допотопных\проблемных, чтобы прийти хоть к какому-то единообразию.
...
Рейтинг: 0 / 0
18.10.2005, 16:40
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33331243
Terrorist
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Terrorist
Участник
Дмитрий Сорокин
tygra
автор- свой механизм транзакций - все изменения вначале записываются в некий пул изменений, измененные объекты лочатся, затем по коммиту все изменения проводятся в БД.
Неужели вы сделали это лучше, чем в MS SQL?!!! Вах!

SQL транзакции не предполагают "протяженности во времени", они должны быть настолько короткими, насколько возможно. Представьте себе, что вы, открыв форму, посылаете серверу BEGIN TRAN, потом что-то там делаете в БД, а потом при нажатии на OK посылаете COMMIT или при нажатии на CANCEL посылаете ROLLBACK. Не буду объяснять недостатков подобного подхода.
У нас есть свой механизм транзакций. Для изменения объектов надо начать такую транзакцию. Упрощенно говоря - при изменении объектов изменения накапливаются, измененные объекты "лочатся" (нашими средствами), при коммите такой транзакции все накопившиеся изменения "накатываются" на SQL сервер, при отмене транзакции - просто объекты возвращаются в состояние "до начала транзакции". До закрытия транзакции есть возможность делать UNDO.

Изобретаете велосипед? И почему транзакции не могут быть растянутыми во времени?
Представьте себе, ваш апп сервер залочил запись в БД... и не разлочил...
Как бороться будете?
В СУБД можно посмотреть кто и как залочил запись(в случае СКЛ-сервера лочятся сразу страницы), и прибить его соединение. В вашем случае увидим, запись залочил апп-сервер.... и что дальше? Рестарт апп-сервера?
Со стороны СУБД и сопровождения системы в целом, такая не тривиальная(почти всегда очень кривая) работа с базой приводит к огромным проблемам... и невилирует все красивости диаграмм и кода на клиенте.
И люди, которые обычно пишут такие системы, потом насилуют кривоватый апп-сервер чтобы оно хоть как-то работало. В результате обычно все маппинг тулы забиваются СУБД зависимыми СКЛ-запросами ...

ИМХО, не надо совмещать то что плохо совместимо... хотите обьекты - не берите РСУБД .... возьмите ООСУБД ..., она в такую логику вписываеться на 100% ....
Зачем над РСУБД издеваться....?
...
Рейтинг: 0 / 0
18.10.2005, 17:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33331688
Дмитрий Сорокин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Сорокин
Гость
TerroristИзобретаете велосипед? И почему транзакции не могут быть растянутыми во времени?
Представьте себе, ваш апп сервер залочил запись в БД... и не разлочил...
Как бороться будете?

Нет у нас сервера приложений! Ну НЕТУ ЕГО!!! Что же все приписывают нам изобретение сервера приложений!
И на сервере ничего не лочится! Это наши личные локи. Это же все много раз проходили: создаете табличку, записываете туда ID объектов, которые редактируете, когда редактирование завершено - стираете оттуда. Плюс сборщик мусора. (Все не совсем так, но по сути - верно)
DrKonito
Не совсем понял. У вас физически одна СУБД с 3000 клиентов написанных на целом зоопарке технологий?
Или это несколько однотипных СУБД с примерно 100 клиентами на завод и возможно некой центральной СУБД куда стекается информация для консолидации?

В любом случае вопросы такого масштаба как у вас, имхо не решаются на технологическом уровне. Расширяемость систем такого масштаба решается не на уровне объектной обертки. Это скорее вопрос к аналитикам, к правильности их видения места системы в контексте предприятия и стратегии её развития в терминах бизнеса. Эти вопросы никак не связаны с технологиями реализации системы.
Мне очень слабо верится, что с появлением объектной обертки начнется "самоорганизация" системы "снизу", скорее это закочится если не хаосом, то очень серьезным усложнением и без того сложного.

Баз у нас множество. Минимум - по одной - на инсталляцию. Плюс - консолидирующие базы. Плюс - разные служебные базы. 3000 клиентов - это общее число пользователей, работающих с системой. Максимальное число одновременных пользователей на 1 базе - 600, размер этой базы - 300Гб.
Речь не идет о расширяемости - скорость нас вполне удовлетворяет. Речь идет о том, что система стала чересчур "сложной", что ее архитектура устарела, что развивать систему становится все сложнее и сложнее.
Я уверен, что это болезнь всех классических двухслойных архитектур. ИМХО- с ростом сложности таких систем резко возрастают затраты на их поддержку и дальнейшее развитие, и именно в этом и состоит главное преимущество многослойных архитектур.
Средний слой мы не хотим применять в принципе - лишние затраты для достижения той же производительности, да и масштабы рефакторинга слишком велики. Мое глубокое убеждение - применяемый нами "объектный" подход, при формальном сохранении двухслойности, позволяет получить все архитектурные преимущества многослойных систем с гораздо меньшими затратами.
Повторяю - все сказанное есть ИМХО.
...
Рейтинг: 0 / 0
18.10.2005, 20:08
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33331696
архитектор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
архитектор
Участник
ACRUS За 3 месяца этот инструмент был реализован, с возможностью аналитикам рисовать на деревьях различные схемы учета движения финансов, вешать различные правила заполнения документов и мониторинга финансовых потоков (правила расширяемые, представлены как SQL-батчи, вешаются на ноды с возможностью их наследования дочерними нодами и выполняются в БД), вешать различные схемы учета на разные предприятия и в разных учетных периодах, а так же вести централизованное управление, администрирование и апгрейт всех РСУБД удаленных узлов, вплоть до удаленного выполнения SQL-скриптов на указанных узлах, с контролем состояния их выполнения. Было бы очень забавно посмотреть, как за такое время, можно было бы такую же функциональность, да еще и работающую, на принципах ООП сделать.

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

Критерий же хорошего проектирования и процесса разработки у меня простой - прибыль, полученная от продажи и сопровождения продукта. Остальное - сложность создания среднего слоя, прелести использования SQL для всей бизнес-логики или ООП - домыслы и размышления, которые проверить невозможно. Каждая команда использует знакомые ей средства разработки и существующие наработки в той области, на которой они специализируются. А обвинить в кривости рук, незнании какой-то фишки в конкретной СУБД и неумении проектировать можно всегда.
...
Рейтинг: 0 / 0
18.10.2005, 20:14
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33331830
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЯ уже приводил пример MFC-шника. Конечно, если у вас мегабайты наработанного кода для вашей СУБД, то вы сделаете такой проект быстро и качественно. И я не кого не призываю все бросить и переписать сущетсвующий код на обертках и т.п. - просто оба подхода имеют право на существование и могут быть лучше или хуже в зависимости от конкретного приложения и конкретной команды разработчиков.
Да нет у меня мегабайтов кода Есть нормальная адекватная РСУБД и платформа для построения клиентской части, которые изначально позволяют делать все описанное. Остается только воспользоваться этими возможностями и поверх сделать адекватный код управления логикой и визуального администрирования, который так же занимает копейки. Это говорит не о подходах, а о выборе платформе - к примеру какой бы подход я не взял, реализация того же самого на базе MSSQL+Delphi действительно заняла бы в десятки раз больше времени, получилось бы в десятки раз больше кода (с меньшим кол-вом возможностей) и действительно были бы мегабайты кода. Ну и естественно самым важным на любой платформе и любом подходе является опыт архитектора проекта, это самый первый пункт в рисках.
...
Рейтинг: 0 / 0
18.10.2005, 22:36
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33332660
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Ну про MSSQL+Delphi и мегабайты коды + и т.д. вы уж загнули

Там тоже нет этого всего - те же копейки. Ну может десятки копеек. :)

-- Tygra's --
...
Рейтинг: 0 / 0
19.10.2005, 12:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33332858
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
tygraНу про MSSQL+Delphi и мегабайты коды + и т.д. вы уж загнули

Там тоже нет этого всего - те же копейки. Ну может десятки копеек. :)

-- Tygra's --
Мегабайты, мегабайты - говорю не просто так, а с реального опыта :) Сначала были проекты на MSSQL+Delphi, теперь проекты на ASA+PB, разница в коде очень значительная, причем последние проекты по обьему и функционалу поболее будут. На ASA многие вещи с учетом более большой функциональности решаются враз, где на MSSQL приходится или выкручиватся или же вообще скидывать на клиентскую часть. На Delphi даже с теми же компонентами DevExpress кода работы логики с интерфейсом не мало получалось (это с учетом того, что своих компонент на все случаи жизни еще порядка 50 было и куча шаблонов форм и классов), на PB реально все покрывает DataWindow + собственная не очень большая иерархия классов и форм, фактически остается только мышкой DataWindow источники данных и их визуализацию рисовать и где нужно парой строчек кода в отнаследованных обьектах приватную логику описывать.
...
Рейтинг: 0 / 0
19.10.2005, 12:55
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33332881
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tygra
Участник
Может вы чего-то такое особенное писали - не вижу никаких мегабайтов кода у себя. В общем случае - пара процедур в модуле и все.
DevExpress не используем - тока EhLib.

Это нужно не тут и поконкретнее разговаривать - что вы делали, что мы, и как реализуется. Я уже писал - несколько минут на добавление основных форм для таблицы.

-- Tygra's --
...
Рейтинг: 0 / 0
19.10.2005, 13:00
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33332949
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DataWindow сильный плюс PB. Жалко, что нет хотя бы близких по функционалу компонентов для дельфей. Что касается самой среды и модели классов, то мне не совсем она нравиться. Но, не будем об этом.
...
Рейтинг: 0 / 0
19.10.2005, 13:21
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #33332970
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
pkarklin
Сама среда PB действительно хреновенькая, модель классов своя и достаточно простенькая, точно на уровне - ровно столько, сколько нужно для хорошей жизни без заморочек и кода. PFC вообще не пользуемся.
...
Рейтинг: 0 / 0
19.10.2005, 13:25
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Создание сервера приложений
    #34699992
DrKonito
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DrKonito
Гость
Извиняюсь перед сообществом, за оживление умершего 1.5 года назад флейма. Но не могу не похвастаться.

DrKonito tygraИ что оно там узнает?
Надо мягко ему рассказывать, как БЛ на сервере объеденить с тем, чего они услышали, дополнить всеми плюсами БЛ на сервере - и все будет хорошо. :))

А что за семинары то? Где там микрософт предлагает БЛ где-то в другом месте?

-- Tygra's --
Оно приходит набравшись слов типа апп-пулинг, ван-клик-деплоймент, компоненты, мнгозвенные приложения, НЕТ-Фреймворк, НЕТ-Фреймворк, НЕТ-Фреймворк ...
Т.к половины этих слов оно не понимает, а слов про бизнес-логику на транзакте там не говорилось, то ход его мыслей примерно таков- написать все на НЕТ и все будет зашибись - об остальном Микрософт позаботится.

Соответсвенно вооружившись такой стратегией начальство набрало несколько человек, которые на собеседовании говорили похожие слова. Теперь эти люди в перерывах между объяснениями почему мы слезли с пальмы и как у нас все плохо, предлагают для начала написать побольше бизнес-логики на шарпе, запихнуть её "для начала" в толстого клиента, а потом уже разбираться с архитектурой :)

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

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

Делайте выводы сами.
...
Рейтинг: 0 / 0
02.08.2007, 09:04
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #34700158
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
DrKonitoНо не могу не похвастаться.

:)
...
Рейтинг: 0 / 0
02.08.2007, 10:07
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #34768804
ыг
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ыг
Гость
Блин...... Читал 2,5 часа. ниасилил
...
Рейтинг: 0 / 0
31.08.2007, 17:10
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #34770798
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
DrKonitoПотрачено около человеко-года трудозатрат.
Легко отделалась. С момента появления СУБД все схемы - это клиент-сервер и никаких многозвенок.
...
Рейтинг: 0 / 0
03.09.2007, 09:57
| Ответить | Цитировать | Написать  
Создание сервера приложений
    #34943534
Фотография -=*ShamaN*=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=*ShamaN*=-
Участник
Простой рабочийСпасибо всем за отзывы.
Извиняюсь за задержку, вчера весь день провёл на конференции.

tygra авторДвухвенные клиент-серверные системы делать научились, хотим сделать трёхзвенное. Может кто знает книги или ссылки, где рассказывается, как делается сервер приложений?

А вам зачем трехзвенное? Просто так или делать нечего? :))

-- Tygra's --

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

Хорошее предложение поступило насчет хп сервера, но это, ИМХО, удобно реализуемо только на MS SQL Server 2005 (из линейки майкрософт).

В филиалах лучше поставить отдельные серверы БД и настроить репликации.
Если даже каналы упадут, работа будет возможна.
...
Рейтинг: 0 / 0
16.11.2007, 01:48
| Ответить | Цитировать | Написать  
440 сообщений из 440, показаны все 18 страниц
  все  
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Создание сервера приложений
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=33&tid=1548944]:
 0ms
get settings:
 7ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 42ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 360ms
get tp. blocked users:
 2ms
others: 9ms
total:  453ms
созд. / загр.: 453ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]