ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
25 сообщений из 318, страница 8 из 13
  8  все
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483454
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andreyweb_foxЛично у нас принято правило: "все обращения к БД только через ХП", а это кардинально отличается по смыслу от "вся бизнес-логика на ХП". Можете обосновать это правило какими-нибудь разумными, нерелигиозными причинами?
Почему вызов insertTable(id=>1,label=>'one') лучше, чем insert into table(id, Label) values(1,'one') ?

На этом форуме это обсуждали много раз. Квалифицированные разработчики как на меня. Имеено на ваш вопрос, процитирую из этого форума, например такой отрывок очень опытного разработчика:
prustrА есть какие-то разумные обоснования такой обертке инсертов/апдейтов?
- Есть. Структура базы почти всегда требует изменений, что там прибаляется что-то убавляется... обычный жизненный цикл. Если запросы упакованы в процедуры, то с клиентом согласовывется только структура передаваемых данных. колонки и типы. Изменения алгоритмов обработки в базе не влияют на работу клиентов, делаются на лету.
Иначе надо переписывать и клиента и БД, а это очень неудобно в плане сохранения работоспособности проекта во время обновления версий.

PS: никакой релиигии здесь нет и быть не может, только опыт. Я рекомендую вам делать только то, что вы понимаете . Если это не понятно - лучше не использовать.
...
Рейтинг: 0 / 0
22.02.2010, 19:23
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483478
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_foxprustrА есть какие-то разумные обоснования такой обертке инсертов/апдейтов?
- Есть. Структура базы почти всегда требует изменений, что там прибаляется что-то убавляется... обычный жизненный цикл. Если запросы упакованы в процедуры, то с клиентом согласовывется только структура передаваемых данных. колонки и типы. Изменения алгоритмов обработки в базе не влияют на работу клиентов, делаются на лету.
Иначе надо переписывать и клиента и БД, а это очень неудобно в плане сохранения работоспособности проекта во время обновления версий.

PS: никакой релиигии здесь нет и быть не может, только опыт. Я рекомендую вам делать только то, что вы понимаете . Если это не понятно - лучше не использовать.
ответ совершенно не в тему. Тем более, когда речь идет об изменении структуры БД, которые естественно должны быть отражены в этих самых "инсертах/апдейтах" и, естественно, в структуре передаваемых данных. Невпопад как-то. Воспользуйтесь своей же рекомендацией.
...
Рейтинг: 0 / 0
22.02.2010, 19:35
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483700
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andrey,

Кстати, вот здесь, по-моему рассмотрено большинство преимуществ такого разделения:
/topic/724491&pg=1

Лично мы прошли через все упомянутые в теме трудности (кроме масштабирования), пока не пришли к упомянутому правилу использования ХП. Также озвучу какие выгоды на нашем опыте позволили ускорить разработку и уменьшить отладку:
1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя. Независимо мог менять логику, так что не приходилось изменять клиентов. На продакшене это очень гибкий подход оказался. Плюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом. При этом разработчику среднего слоя БД-программист просто передавал спецификацию пакетов с комментариями о назначении функций, не приходилось обьяснять в какие таблицы что писать, какие физические и логические связи между таблицами и т.п. Человек проектировал БД, создавал таблицы и функции и передавал работу дальше. За функцией мог скрываться как простейший инсерт, так и сложнейшая логика по массовой обработке данных - полная инкапсуляция логики для работы с БД.
2. Второй важный выигрыш: весь программный код, который обращается к таблицам находится в одном месте - в СУБД. Те же Oracle, DB/2 (и др возможно) позволяют отслеживать связи, так что при рефакторинге никогда не встанет вопрос перелапачивания мегабайтов php-кода с целью понять кто использует "эту" таблицу и что он там в неё пишет. Просто выбираете в контекстном меню на таблице пункт "посмотреть связи" и видно все функции, которые используют данную таблицу. Даже если пришлось кому-то написать динамический SQL, то через системные представления такой код легко находится.

Подход оказался на редкость удачным. Возможно для вас это не актуально, я спорить или навязывать ни в коем случае не собираюсь, это только мой опыт.
...
Рейтинг: 0 / 0
22.02.2010, 21:56
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483764
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Senya_L
Участник
web_foxПлюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом .А не выходит так, что разработчик одного из слоя ждет исполнителя другого слоя? Спрашиваю без критицизма, просто интересно.
...
Рейтинг: 0 / 0
22.02.2010, 22:57
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483770
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя. Независимо мог менять логику, так что не приходилось изменять клиентов. На продакшене это очень гибкий подход оказался. Плюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой.
а в чем заключается работа "разработчика среднего слоя". По тому, что Вы описали, такого "человека" просто не получается.
...
Рейтинг: 0 / 0
22.02.2010, 23:04
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36483835
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Senya_Lweb_foxПлюс, чёткое разделение профнавыков программистов, иначе "любой из наших JAVA программистов просто превратится в DBA поневоле, с соответствующей дефицитностью и окладом". Отдельный человек разрабатывает интерфейс, отдельный - БД с ХП, отдельный - средний слой. Каждый занимается своим делом .А не выходит так, что разработчик одного из слоя ждет исполнителя другого слоя? Спрашиваю без критицизма, просто интересно.

Такого быть никак не может. Есть руководители проектов, общий пул ресурсов и планы проектов - всё распланировано, никто не втыкает. Специалисты по БД проектируют и реализуют много всего разного, от OLTP и логики работы с данными, до ETL/хранилищ данных. Работы их профиля море. Бизнес в телекоме очень динамичный, IT-департамент стоит на конвеере, проекты расписаны на 5 лет вперёд. За счёт такого разделения много выигрышей, как при феодальном строе выигрыш от разделения труда - эти сеют, эти пашут, эти ткут. Программисты средних слоёв обычно не настолько хорошо разбираются в БД, чтобы настолько профессионально проектировать таблицы, разбирать планы запросов, анализировать статистику, владеть хинтами, выбирать в нужный час битмеп-индексы, сегментирования, материальные представления - это отдельная епархия, это люди, которые сруки используют аналитические функции, цитируют Тома Кайта и следят за конференциями связанными с БД, они мастера своего дела и пишут качественный код. Java, C#, PHP-прогеры и прочие болеют совсем другими вещами, решают задачи в которых профессионалы они.
...
Рейтинг: 0 / 0
22.02.2010, 23:49
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484460
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
web_fox1. Наибольший выигрыш мы получили от того, что БД-разработчик мог разрабатывать логику работы с данными независимо от разработчика среднего слоя.
Много вы букв написали. Попробую прокомментировать.

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

web_foxПри этом разработчику среднего слоя БД-программист просто передавал спецификацию пакетов с комментариями о назначении функций, не приходилось обьяснять в какие таблицы что писать, какие физические и логические связи между таблицами и т.п. Я правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?

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

web_fox2. Второй важный выигрыш: весь программный код, который обращается к таблицам находится в одном месте - в СУБД. Те же Oracle, DB/2 (и др возможно) позволяют отслеживать связи, так что при рефакторинге никогда не встанет вопрос перелапачивания мегабайтов php-кода с целью понять кто использует "эту" таблицу и что он там в неё пишет. Просто выбираете в контекстном меню на таблице пункт "посмотреть связи" и видно все функции, которые используют данную таблицу. Даже если пришлось кому-то написать динамический SQL, то через системные представления такой код легко находится.Хорошие костыли для неумения работать с исходными кодами. Особенно порадовал поиск в системных представлениях. :) То есть перелопатить мегабайты pl/sql кода проблемы не представляет, а вот с php-кодом - сложности.
Я правильно понимаю, что понять кто из среднего слоя выполняет Insert into table вы не можете, а кто вызывает процедуру insertTable - умете?

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

Давайте попробуем на конкретном примере. Пусть мне надо сделать, скажем, справочник валют. Я в СУБД просто сделаю таблицу Currency(Id, Name, CodeISO). Пользовательский интерфейс для ведения справочника "руками" будет делать одни запросы. Механизм загрузки из файла - другие и т.п. А сколько процедур вам понадобиться? И какие конкретно проблемы эти процедуры смогут решить?
...
Рейтинг: 0 / 0
23.02.2010, 15:53
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484582
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyЯ правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?
угу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)
INSERT INTO dbo.a_flat_list
( street_id, build_num, build_char, room_num, room_char,flat_num ) VALUES (....);

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
CREATE PROCEDURE [dbo].[proc_flat_add_new]
@street_id  int ,
@build_num  int ,
@build_char varchar( 2 ),
@room_num   int ,
@room_char  varchar( 2 )
AS
BEGIN
   DECLARE @retry    INT;
   DECLARE @err_msg  VARCHAR( 255 );
   DECLARE @err_proc VARCHAR( 100 );
   DECLARE @log_msg  VARCHAR( 255 );
   DECLARE @flat_id  INT;

   SET @retry   =   5 ;
   
   SET NOCOUNT ON;
   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   SET LOCK_TIMEOUT  1000 ;
   
   if @build_num =  0  set @build_num = null;
   if @room_num  = 0   set @room_num  = null;
   
   
   -- проверит что квартиры с такими буквами и номерами нет в базе
   SELECT @flat_id = a.flat_id
   FROM dbo.a_flat_list a
   WHERE a.street_id  = @street_id
   AND   a.build_num  = @build_num
   AND   a.build_char = @build_char
   AND   a.room_num   = @room_num
   AND   a.room_char  = @room_char;
   
   if @flat_id >  0  begin
     set @err_msg = 
       'Такая квартира (частный дом) уже существует '+CHAR( 13 )+CHAR( 10 )+
       'Выполнение операции невозможно';
     if @@TRANCOUNT >  0  rollback;raiserror(@err_msg,  16 ,  1 );return;       
   end;  
   
   WHILE (@retry >  0 )
   BEGIN
     BEGIN TRY
       BEGIN TRANSACTION;  
       --------------------------------------------------------------
       SELECT @flat_id=- 1  FROM dbo.a_flat_list   WITH(TABLOCK);
       SELECT @flat_id=- 1  FROM dbo.a_street_list WITH(TABLOCK);
       
       INSERT INTO dbo.a_flat_list 
       ( street_id, build_num, build_char, room_num, room_char,
         flat_num 
        )
       VALUES
       ( @street_id,@build_num,@build_char,@room_num,@room_char,
        dbo.fun_get_addrnum(
                    @build_num,@build_char,@room_num,@room_char)
        );
       
       SELECT @flat_id=SCOPE_IDENTITY();
       
       SELECT @flat_id AS flat_id;
       --------------------------------------------------------------
       SET @retry = - 5 ;
       COMMIT TRANSACTION;
     END TRY BEGIN CATCH 
       SET @err_msg = dbo.fun_get_error_info();SET @err_proc = ERROR_PROCEDURE();
       IF((ERROR_NUMBER() =  1205 )OR(ERROR_NUMBER() =  1222 ))  
            SET @retry = @retry -  1 ;           
       ELSE SET @retry = - 1 ;
       IF XACT_STATE() <>  0  ROLLBACK TRANSACTION;
     END CATCH;
   END; -- End WHILE loop.
   IF @retry <> - 5  BEGIN 
      EXEC dbo.proc_log_add_error @err_proc,@err_msg;RAISERROR(@err_msg, 16 , 1 );RETURN;
   END;
   SET @log_msg = 'flat_id='+convert(varchar, @flat_id);
   EXEC dbo.proc_log_add  0 ,'proc_flat_add_new',@log_msg;
   SELECT @flat_id;
END
после, для себя взял за правило, если есть возможность - все только через хранимки, и обязательно все действия в логи.
...
Рейтинг: 0 / 0
23.02.2010, 17:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484614
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
жесть, как говорится
...
Рейтинг: 0 / 0
23.02.2010, 17:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484641
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Bogdanov Andrey,

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

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

Возьмите, пожалуйста, бумагу и нарисуйте два слоя: Слой БД и Клиента.

Вариант1: Клиент использует БД-функцию GetCurrencyById(Id):ArrayOfProperty.
Вариант2: Клиент напрямую читает из таблиц БД.

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

Вариант1: Меняется логика функции. Для клиента всё остаётся прозрачно.
Вариант2: Меняется логика функции. Нужно изменить клиента тоже.

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

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

Или у вашей компании не хватает денег, чтобы отдельно нанять БД-разработчика и не заставлять людей учить признаки, при которых нужны битмеп-индексы (кстати, вы знаете что это такое?), или лично у вас опыт написания только простейших проектов, а ля погонять справочники туда-сюда.
...
Рейтинг: 0 / 0
23.02.2010, 18:11
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484647
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
Кифирчик,

во, видно опытного человека. Причём очевидно, что если бы данная логика была на клиенте, то запросов бы в базу было несколько, а так один.
...
Рейтинг: 0 / 0
23.02.2010, 18:15
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484655
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox,

web_foxВижу, что вы не понимаете этих вещей просто по неопытности. Это не в обиду, но вопросы выглядят просто незрелыми, да ещё с оттенком задаваки
...
Рейтинг: 0 / 0
23.02.2010, 18:19
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484705
web_fox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
web_fox
Участник
авторSQL-интерфейс к реляционным данным гораздо более гибок, удобен и надежен. Никакими храниммыми процедурами не реализовать и половины его возможностей.

Из это предложения следует, что вы не понимаете что пишите. Студент? 8)
...
Рейтинг: 0 / 0
23.02.2010, 18:45
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484743
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
web_fox,
речь идет о динамическом SQL, который формируется инструментами "среднего слоя". Вы не понимаете о чем вообще речь идет. Студент?
...
Рейтинг: 0 / 0
23.02.2010, 19:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36484788
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
банальная задачка: есть набор записей, в котором по определенному условию нужно заменить значение одного, допустим, поля. Полагаю, что коллега Bogdanov Andrey динамически сформирует update...where и передаст серверу СУБД на исполнение. А что нужно сделать в случае следования принципу "все модификации БД только через ХП"?
Варианты ответа:
1. Написать очередную ХП для выполнения этого действия
2. Поочередно отредактировать каждую запись, которая вызовет назначенную для этого действия ХП. Тяжело? А кому сейчас легко.
3. Написать нечто с динамически изменяемым набором параметров и динамически формируемым SQL в ХП
4. А нафига это вообще нужно.
...
Рейтинг: 0 / 0
23.02.2010, 19:37
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485113
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Одна из составных частей бизнес-логики - валидация вводимых значений.

Вопрос, где должна быть эта часть бизнес-логики если:

1. К базе данных обращаются разные программы
2. Клиент должен поддерживать хотя бы частичную работу оффлайн
3. Трафик между клиентом и МТ требуется минимизировать
4. Некоторые проверки требуют обработки больших массивов информации
5. Все выше перечисленное?

Наводящий вопрос: На каком элементе трехзвенки можно НЕ имплементировать валидацию в ситуации (5)?
...
Рейтинг: 0 / 0
24.02.2010, 09:05
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485163
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
drev,

если отбросить вопрос о валидации ввода, как о составной части бизнес-логики, то наводящий вопрос: о чем речь идет?
...
Рейтинг: 0 / 0
24.02.2010, 09:50
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485193
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
iscrafmdrev,

если отбросить вопрос о валидации ввода, как о составной части бизнес-логики, то наводящий вопрос: о чем речь идет?

А вы попробуйте не отбрасывать:)

Ответив на поставленные мной вопросы, можно определить на каких тирах нам нужно иметь бизнес-логику, а на каких - необязательно.
...
Рейтинг: 0 / 0
24.02.2010, 10:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485231
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
dreviscrafmdrev,

если отбросить вопрос о валидации ввода, как о составной части бизнес-логики, то наводящий вопрос: о чем речь идет?

А вы попробуйте не отбрасывать:)

Ответив на поставленные мной вопросы, можно определить на каких тирах нам нужно иметь бизнес-логику, а на каких - необязательно.
чтобы ответить на эти вопросы и не отбрасывать определение валидации, ответьте на наводящие вопросы.
Есть форма ввода транзакции по платежной карте. В качестве входящих данных требуется номер карты, имя владельца, срок действия, CVV2-код. Что вы относите к валидации ввода?
Судя по вопросам - процедуру авторизации транзакции? Или все же проверку того, чтобы номер какрты состоял из 16 цифр, а cvv2 из 3-х и т.п.?
...
Рейтинг: 0 / 0
24.02.2010, 10:31
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36485288
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
немного расшифрую вопрос...
часто путают понятия валидация и верификация, аутентификация и авторизация и т.п. Само сочетание "валидация ввода" звучит немного корявенько, поэтому хочется понять о чем идет речь. Если о проверке вводимых значений, то клиент именно то место, где такой проверке самое место (тавтология). Если речь идет о проверке возможности применения в системе введенной (полученной другими способами входящей информации) то это как раз и является предметом спора в данной теме. Тогда лучше выскажите свое мнение по данному вопросу.
...
Рейтинг: 0 / 0
24.02.2010, 10:52
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486597
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикугу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.

web_foxВариант1: Клиент использует БД-функцию GetCurrencyById(Id):ArrayOfProperty.
Вариант2: Клиент напрямую читает из таблиц БД.

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

web_foxСмотрим что получается.А теперь смортим еще и замечаем, что надо сделать загрузку валют из текстового файла.

Вариант1: Создаем новую функцию GetCurrencyByCode и меняем клиента
Вариант2: Просто меняем клиента.

Затем в табличку добавляется поле CodeISONum (для всех валют есть цифровые коды).
Вариант1: Переписываем функцию и меняем клиента
Вариант2: Просто меняем клиента.

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

web_fox- мы ближе к "идеально разработанной системе" (чем лучше спроектирована система, тем меньше нужно сделать изменений при изменении бизнес-процесса). Мы поменяли один слой, а не два - это быстрее, это удобней, это понятней, а для продакшн-системы минимизация рисков при накатывании релизов.Я еще раз повторю - покажите мне реальные примеры, пока были только теоретизирования. И пожалуйста, без примеров бизнес-логики в ХП. Пока же я вижу, что 90% всех изменений у вас гарантированно затроет и БД и СП. Еще примерно 10% затронут только СП, ну и оставшееся на случай изменения только в БД. В моем варианте примерно 60%-70% изменений затрагивают только СП. Очевидный выигрыш моего варианта по данному показателю.

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

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

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

web_foxИли у вашей компании не хватает денег, чтобы отдельно нанять БД-разработчика и не заставлять людей учить признаки, при которых нужны битмеп-индексыЯ правильно понимаю, что написать insert into table без знания bitmap-индексов никак нельзя...

web_fox (кстати, вы знаете что это такое?), или лично у вас опыт написания только простейших проектов, а ля погонять справочники туда-сюда.Ага, сейчас будем проектами меряться. Может быть сначала про свой богатейший опыт расскажете? А то ведь такие умные слова знаете, "битмап"...
...
Рейтинг: 0 / 0
24.02.2010, 19:01
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486605
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
drev1. К базе данных обращаются разные программыЕсли разные программы обращаются именно к базе данных, то естественно, что база данных должна представлять собой целостный сервис и все проверки обеспечивающие эту целостность должны быть в БД.

Но обычно (по крайней мере в последнее время), если одними данными пользуется несколько разных программ, то существует некий централизованный сервер приложений, предоставляющий им интерфейсы.
...
Рейтинг: 0 / 0
24.02.2010, 19:09
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486833
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov AndreyКифирчикугу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.

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

Bogdanov AndreyКифирчикBogdanov Andrey
Я правильно понимаю, что обяснить сделай "insert into..." существенно сложнее, чем вызови процедуру "insertInto". Неужели все так плохо с разработчиками среднего слоя?
угу... я тоже сперва думал что INSERT это просто INSERT, и писал (к примеру)...Сразу видно человека который не отличает бизнес-логику от данных. Прмер, в котором ХП реализуют бизнес-логику никак не доказывает того, что вся работа с данными должна вестись через процедуры.
вы это вообще о чем?...
какая бизнес-логика? я просто првел пример, что ОЧЕНЬ часто, нельзя из программы просто писать INSERT INTO, и это черевато проблемами.
И если "по нормальному", то прежде чем написать INSERT INTO, программисту надо запустить транзацию, залочить нужные таблицы, сделать проверки, и незабыть обработать исключительные ситуации с обязательными rollback в случае чего.
А в данном примере, надо только вызвать хранимую процедуру - 5..7 строчек кода, и более того, для "сущности" есть класс, с именами как в базе, и когда надо добавить новую, просто пишется
Код: plaintext
1.
2.
flat_item.street_id :=  10 ;
flat_item.build_num :=  7 ;
flat_item.proc_flat_add_new();
Так что хранимку вызвать точно проще чем INSERT INTO "как надо"...

на счет битмэп не знаю, но без знания хинтов... с INSERT.. написать можно, но я бы не подпускал :-)

И даже если бы мне надо было разбить приведенное выше приложение, на 3 уровня, то в сервере приложений (к примеру для работы через XML, для нестабильных соединений, чтоб не держать простоянный коннект) я бы сделал "обертку" для базы, с всякими буфферизациями, кэшированием... логику оставил бы в базе.
Именно для этого приложения, оптимум - логика в базе.
Конечно не исключаю, что в других случаях будет наоборот.
...
Рейтинг: 0 / 0
24.02.2010, 22:02
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486888
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Кифирчикобалдеть, ну так вы в цитату фразу вставьте, пытаясь ответить на которую, я привел примерЛегко.
Вы отвечали на мой пост в котором сказано:
"Если логика реализована в БД, то естественно надо вызывать процедуры выполняющие эту логику. Но вы выдвигаете "абсолютное" требование - любое обращение к БД через ХП."

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

Кифирчиквы это вообще о чем?...
какая бизнес-логика?
Вообще-то я плохо разбираюсь в MSSQL, но открытие и завершение транзакции внутри ХП для меня однонзачно указывает на то, что данная процедура реализует некоторый целостный кусок бизнес-логики, а никак не отдельную интерфейсную операцию базы данных.
...
Рейтинг: 0 / 0
24.02.2010, 22:50
| Ответить | Цитировать | Написать  
Где должна лежать бизнес-логика в мнгоуровневом приложении
    #36486930
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
Bogdanov Andrey[
Кифирчиквы это вообще о чем?...
какая бизнес-логика?
Вообще-то я плохо разбираюсь в MSSQL, но открытие и завершение транзакции внутри ХП для меня однонзачно указывает на то, что данная процедура реализует некоторый целостный кусок бизнес-логики, а никак не отдельную интерфейсную операцию базы данных.
Когда с базой работает один пользователь - это все лишнее...
но когда их много, могут возникнуть проблемы при обращении к одним ресурсам...
когда кто-то вызвал "UPDATE", в MSSQL, как блокировочнике, таблица "блокируется" пока этот апдейт не выполнится... и когда туда тыркаются другие, они получают болт...
так вот "блокировка" должна распонзаваться и соответсвующим образом обрабатываться, что и приведено в примере... само собою и элементы логики надо в это оборачивать
иначе, возникают всякие висячие транзакции, заблокированные ресурсы, ролбэки, охватывающие час работы всех пользователей... ох я шишок в начале с этим набил...

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

отвечая на ваш пост, я не абсолютизировал "доступ к БД" через хранимки, я хотел сказать, что в некоторых случаях без хранимок либо вообще ни как, либо очень тяжко, даже еcли отбросить логику и говорить о простых INSERT
...
Рейтинг: 0 / 0
24.02.2010, 23:27
| Ответить | Цитировать | Написать  
25 сообщений из 318, страница 8 из 13
  8  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Где должна лежать бизнес-логика в мнгоуровневом приложении
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=36484647&tid=1542824]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 151ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 51ms
get tp. blocked users:
 1ms
others: 247ms
total:  489ms
созд. / загр.: 489ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]