Здравствуйте, MozgC, Вы писали:

MC>Здравствуйте, VladD2, Вы писали:

MC>>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.
VD>>Это реализация логики на исключения. Нужны объяснения почему — это плохо?

MC>Да, пожалуйста.

Знаешь почему люди отказались от использования goto (особенно позволяющего передать управление глобально)?
Потому что такие программы практически невозможно отлаживать. Они не структурны и нельзя делать предположения о их поведении.
Та же фигня с исключениями. Они позволяют передавать управление не структурно. К тому же в дотнете нельзя описать, что метод возвращает исключение, а значит нельзя гарантировать, что исключение которое планировалось как обязательное для обработки таки будет обработано. В результате когда код становится большим, то отследить полеты исключений становится очень сложно.

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

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

Здравствуйте, VladD2, Вы писали:

VD>О. Ты будешь потрясен. Я рассуждаю так, как будто DAL больше не нужен. Это еще прикольнее .
VD>Зачем мне DAL если я пользуюсь типизированными запросами? Чем в этом случе DAL отличается от бизнес-логики?

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

VD>Возьмем к примеру этот сайт. Зачем мне делать какие-то бизнес-объекты чтобы отобразить информацию о сообщениях форума? А зачем бизнес-объекты чтобы вывести список твоих оценок?

Форум это не типичное приложение.

VD>Для таблиц использовать простой мапинг один к одному (таблица на один простой объект). Для выборок в которых не требуются все поля из таблицы или требуются поля из разных таблиц использовать кортежи или анонимные типы.

К сожалению простой мапинг один-к-одному не всегда удачное решение, с точки зрениякак нормализации БД, так и дальнейшей поддержки.

VD>В общем, получать списки данных и обрабатывать их. Если нужны все данные по сущности (в том числе получаемые по вязям), ну, что же создадим запрос с джоинами. Точнее linq позволяет их представить в виде свойств и избежать прямых джоинов, но это уже детали реализации. В тоге все равно будет один комплексный запрос в БД.
VD>В общем, это можно назвать — назад в будущее! Мы как бы возвращаемся в прошлое когда мы писали текстовые запросы к СУБД и обрабатвали их в своем любимом языке, но на новом уровне. Теперь запросы типизированные и нам не нужен ни дал, ни сложные TSQL. Более того. Получив список мы можем продолжить обрабатывать его теми же запросами, но уже локальными.
VD>Задача обработки данных превращается в задачу трансформации данных.
VD>В таких условиях ООП используется скорее для организации логики программы, а не для представления данных.

То что ты говоришь хорошо для веба. Более или менее толстые клиенты так не напишешь.

Здравствуйте, IT, Вы писали:

MC>>Я бы вызвал исключение, а уже бизнес-логика бы решила что делать с тем, что такой темы нет.
IT>Это назвается строить логику на исключениях, практика, за которую нужно не просто отбивать пальцы линейкой, а лучше даже что-нибудь отрезать.

Пальцы надо отбивать за безличный return null из которого не ясно что и где произошло.

MC>>Вообще так можно про все сказать "что тут исключительного". К примеру пытаемся прочитать файл, а такого файла нет (его уже пользователь удалил), ну а что тут исключительного, давайте признак возвращать.
IT>Вот хороший пример. Можно ещё обсудить вариант с разрешением к доступу к файлу. Твой backup процесс пытается скопировать файл, а он недоступен, по твоей логике есть только один путь — кинуть исключение и прервать процесс. Такой бекапер будет выброшен сразу же после первой проблемы с потерей информации.

Вообще-то исключения надо ловить, а не только кидать

Здравствуйте, gandjustas, Вы писали:

G>Не-не-не, дэвид блейн, не-не. Не надо ООП тянуть в организацию логики программы. Для логики подходит модель SOA.

SOA — это очередной базворд. Раньше это называли RPC, но потом в этом названии нашли фатальный недостаток .

Логика программы — это несколько другое. Скажем клиентское оконное приложение использует ООП для управления онками и организации цикла обработки сообщений. Веб-сервер использует ООП для организации своей структуры и инкапсуляции таких вещей как сессии.

G>Всля логика разбивается на сервсиные классы, которые в идеале stateless, в качестве SOA-интерфейсов используются интерфейсы языка, в качестве брокера — IoC контейнер. Методы сервисов создают цепочку вызовов, которая формирует запросы, не материализуя их без необходимости.

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

G>IoC контейнер в возможностями перехвата (runtime AOP) позволяет также навешивать авторизацию, кеширование и другие вкусности без затрагивания логики.

У нас свои подходы. Людям познавшим, что такое макросы костыли вроде AOP и IoC становятся не нужны.

Здравствуйте, VladD2, Вы писали:

A>>По-моему, в твоём примере налицо race condition. Надо либо запретить удалять из базы данных (я за этот метод), а только помечать сообщение как удалённое, либо смириться с тем что DAL кинет исключение, потому что блокировать ресурс-сообщение нельзя. В BL его можно обработать, а можно даже не обрабатывать. В конце концов я могу прямо в URL вбить номер несуществующего сообщения.
VD>Зачем мне мериться? Проще возвращать что надо и проверять результат.

А что надо? Сообщение может быть недоступно потому что нет прав доступа, потому что самого сообщения нет, потому что сообщение не доступно анонимным пользователям. И на все случаи жизни у нас будет return null? Бу-га-га.

Здравствуйте, VladD2, Вы писали:

VD>А зачем, собственно? Мы ведь должны были выбрать список тем для форума. Или данные по клиенту.

Влад я говорю не про форум и не про отчёты с дистрибуции. Есть и другие задачи, выходящии за пределы select из таблицы Orders.

Здравствуйте, VladD2, Вы писали:

VD>Потому что такие программы практически невозможно отлаживать. Они не структурны и нельзя делать предположения о их поведении.
VD>Та же фигня с исключениями. Они позволяют передавать управление не структурно. К тому же в дотнете нельзя описать, что метод возвращает исключение, а значит нельзя гарантировать, что исключение которое планировалось как обязательное для обработки таки будет обработано. В результате когда код становится большим, то отследить полеты исключений становится очень сложно.

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

VD>Кроме того если в программе исключения исползуются только для обработки исключительных стуаций (читай ошибок), то их проще отлаживать. Ведь можно просто включить перехват всех исключений и при возникновении оного просто разобраться, что же произошло. Если же в программе летает куча исключений, то разобраться будет очень не просто.

Вообще-то тут и говорится про обработку ошибки. Ситуация считается ошибочной и для её, ошибочной ситуации, обработки используется исключение.

Здравствуйте, MozgC, Вы писали:

G>>Как обрабаотывать случай отсутсвия в базе записи с нужным ID — уже дело BL, причем способ обработки сильно зависит от варианта использования.
MC>Нет, целостность данных — должна контролироваться в DAL и БД. Отствие записи с нужным ID — это исключительная ситуация, и DAL в таком случае должен выбрасывать исключение. И вот дальше уже да, дело бизнес-логики как обрабатывать это исключение.

Собственно, если мы договорились о том, что "Отсутвие записи с нужным ID — это исключительная ситуация" то бизнес-логике думать уже не о чем. Надо культурно уведомить об ошибке.

Здравствуйте, gandjustas, Вы писали:

G>Нельзя в принципе. Даже сама СУБД не умеет так.
G>Думаешь почему есть Estimated Execution Plan, а есть реальный план исполнения запроса?
G>Можно только предположить, а это как раз преждевременная оптимизация, которая ни к чему хорошему не ведет.

Предположить можно с высокой спенью достоверности. То что ты описал наблюдается по той простой причине, что SQL Server хранит и использует статистику уже выполненных запросов.
Вместо того чтобы создавать хаос, как предлагаешь ты, а потом тюнинговать БД чтобы этот хаос работал с приемлемой скоростью, можно создать изначально упорядоченный DAL и не надо будет ничего тюнинговать.

A>>А что, ваш метод защищает от "грамотного" админа? Да и вообще, насколько актуальна эта проблема?
G>Мой метод не защищает, и не дает иллюзию защиты, в отличие от ...

Ты себе что-то напридумывал...

Здравствуйте, adontz, Вы писали:

A>DAL отличается от бизнес-логики назначением. DAL поддерживает инфрастурктуру: целостность данных, транзакции, права доступа на уровне строк. А вот как этим всем пользоваться решает BL.

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

Но я не против если в приложении требущем сложной логики ввода данных будет код отвечающий за это.
Но ты же не говорил о записи данных. Правда? Ты говорил о DAL как о месте где хранятся методы доступа.
Это было нужно когда методы доступа внутри себя содержали SQL в виде строк. А зачем они если мы оперируем с данными типизированными запросами?

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

VD>>Возьмем к примеру этот сайт. Зачем мне делать какие-то бизнес-объекты чтобы отобразить информацию о сообщениях форума? А зачем бизнес-объекты чтобы вывести список твоих оценок?

A>Форум это не типичное приложение.

Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.

A>К сожалению простой мапинг один-к-одному не всегда удачное решение, с точки зрения как нормализации БД, так и дальнейшей поддержки.

Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.

A>То что ты говоришь хорошо для веба. Более или менее толстые клиенты так не напишешь.

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

Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.
А мы вот мастодонты. Просидели век ОРМ-ов в подвалах и вылезли на свет в момент когда они изжили себя. Но к счастью (или несчастью) в этот самый момент на арену вышел ФП. Он отлично лег на датацентричный подход и оказался более удобным для обработки данных.
Linq — это почти то что нужно. Осталось приделать DML. Решить проблемы производительности. И мы получим отличное решение датацентричных задач.

Здравствуйте, adontz, Вы писали:

VD>>А зачем, собственно? Мы ведь должны были выбрать список тем для форума. Или данные по клиенту.

A>Влад я говорю не про форум и не про отчёты с дистрибуции. Есть и другие задачи, выходящии за пределы select из таблицы Orders.

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

Здравствуйте, adontz, Вы писали:

A>Влад, ты говоришь несусветную глупость.

Я бы на твоем месте не был бы так категоричен .

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

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

A>Вообще-то тут и говорится про обработку ошибки. Ситуация считается ошибочной и для её, ошибочной ситуации, обработки используется исключение.

Не. Вы говорите не об ошибках. Если темы нет в БД — это не ошибка. Это нормальная ситуация, по крайней мере может быть таковой.

Здравствуйте, VladD2, Вы писали:

VD>По возможности не надо переносить задачу контроля целостности данных (ссылочной целостности) на программы. РСБУД это делают оптимальным образом — декларативно.

Да, в большиснтве случаев так и есть.

VD>Но я не против если в приложении требущем сложной логики ввода данных будет код отвечающий за это.
VD>Но ты же не говорил о записи данных. Правда? Ты говорил о DAL как о месте где хранятся методы доступа.

Ну вообще-то DAL должен поддерживать запись данных

VD>Это было нужно когда методы доступа внутри себя содержали SQL в виде строк. А зачем они если мы оперируем с данными типизированными запросами?

Типизированный запрос всё равно должен фильтроваться правами доступа на уровне строк А JOIN которые ты пытаешься мне пихнуть, всё становится даже сложнее.

VD>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.

А что ты опроверг?

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

Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.

VD>Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.

Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?

Здравствуйте, adontz, Вы писали:

A>А что надо? Сообщение может быть недоступно потому что нет прав доступа, потому что самого сообщения нет, потому что сообщение не доступно анонимным пользователям. И на все случаи жизни у нас будет return null? Бу-га-га.

Это у вас null. А у нас будет пустой список. И никто не говорит, что это решение на все случаи. Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.

Здравствуйте, adontz, Вы писали:

A>Собственно, если мы договорились о том, что "Отсутвие записи с нужным ID — это исключительная ситуация" то бизнес-логике думать уже не о чем. Надо культурно уведомить об ошибке.

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

Здравствуйте, VladD2, Вы писали:

VD>Все зависит от логики. Если речь идет об исклчении, т.е. ошибке которая возникает в случае непредвиденных (заранее) обстоятельств, то конечно будет исключение и стандартная обработка.

Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БД (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?

Здравствуйте, MozgC, Вы писали:

MC>И обрабатываю в БД

в БЛ ***

Здравствуйте, adontz, Вы писали:

A>Ну вообще-то DAL должен поддерживать запись данных

Вообще? А у тебя? Ты нам все время приводишь методы вроде Find и Get. Вот их то мы и не хотим видеть.

A>Типизированный запрос всё равно должен фильтроваться правами доступа на уровне строк А JOIN которые ты пытаешься мне пихнуть, всё становится даже сложнее.

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

VD>>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.

A>А что ты опроверг?

Твои утверждения.

VD>>Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.

A>Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.

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

VD>>Просто ты сросся с догмами. ОРМ-ы так замечательно навязывали свои идеи на протяжении 10 последних лет, что в итоге многие уже считают только их подход единственно возможным.

A>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?

Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л!
Это тупик. Счастливого пути в этом направлении.

Здравствуйте, MozgC, Вы писали:

MC>Ну вот допустим идет запрос производителя по ID, и тут оказывается что такого производителя нет (а должен быть). Я кидаю из DAL исключение. И обрабатываю в БЛ (вывожу сообщение об ошибке пользователю и логирую саму ошибку). Что не так то?

Все бы ничего если бы не требовалось обработки в БЛ. А раз она есть, то ты строишь логику на исключениях.

Запомни на всю жизнь. Или это исключение, или ты не обрабатываешь его в логике.

Для обработки исключений должны быть специальные места. Ими не должен быть утыкан весь код.

Здравствуйте, VladD2, Вы писали:

VD>Вообще? А у тебя? Ты нам все время приводишь методы вроде Find и Get. Вот их то мы и не хотим видеть.

Ты считаешь что должен быть только один Query?

VD>>>Кому как. Но это и не важно. Важно, что если гипотеза опровергается примером, то это неверная гипотеза.
A>>А что ты опроверг?
VD>Твои утверждения.

А ну ладно, а то я не заметил.

VD>>>Нормализация БД тут не причем, так как мы не подгоняем сущности под объекты, а просто отображаем сущности (т.е. данные) на плоские типы. В общем, ООП идет лесом.
A>>Ты забыл про "дальнейшую поддержку". Дело в том, что база данных, по возможности, не должна анализировать данные, поэтому, зачастую, сущность отображается на несколько таблиц. Типичный пример, связанная таблица (ObjectID, PropertyName, PropertyValue). Преимущество такого подхода очевидно, рефакторинг BL сущности не прокатывается цепной волной по DAL. Меньше надо писать, меньше тестировать.
VD>Ты повторяешься. Я уже отвечал сто раз, что ошибочны твои предположения и суждения об объектах. Они не применимы к БД. Не надо проектировать БД под объекты.

Я проектирую БД не под объекты, а под рефакторинг. или рефакторинг ты тоже отменил?

A>>Если ты заметил, я не считаю ORM лучшим решением. Как это согласуется с твоими выводами?
VD>Ты мыслишь их понятиями. Ты уже достал своей идеей проецирования объектов на БД. По буквам Д О С Т А Л!
VD>Это тупик. Счастливого пути в этом направлении.

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