Здравствуйте, Doc, Вы писали:
IT>>А какое за этим поинтом логическое обоснование? Кроме "IMHO не правильно". Doc>Вот тут в конце сообщения. Doc>http://www.rsdn.ru/forum/design/5052475
Там нет логического обоснования. Там есть примерно такое — хочу абстракцию и фсё. Какие проблемы она решает не указано, кроме не очень большой проблемы совместимости разны SQL, которая решается либо выбором правильного инструмента, либо небольшими хелперами.
Можно я приведу пример логического боснования против разбиения логики приложения на слои? Спасибо.
Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям. Что в свою очередь приводит к значительному увеличению объёма кода, ужудшению восприятия и дополнительному усложнению при его модификации. Как привило, в размазанном по слоям коде BL соостоит более чем наполовину их мусора типа path-through методов. Дополнительные проблемы сюда вносит попытка повторного использования бизнес логики. Здесь ситуация получается с точностью до наоборот. В один и тот же метод вносятся части слабо связанных друг с другом алгоритмов, внутренняя логика метода строится на флажках параметрах или в зависимости от вторичных половых признаков передаваемых в метод объектов. В результате чего очень скоро в процессе модификаций в коде появляются сначала фантомные параметры методов, а затем и сами фантомные методы. Модифицировать такие методы на порядок сложнее по причине их повышенной хрупкости, приходится изучать логику работы всего что их вызывает.
Вот это всё реальные проблемы, которые возникают при разбиении цельного алгоритма на слои. Это было всегда и так и останется навсегда просто потому что за всё надо платить. Но в случае изпользования DAL, как изолятора приложения от работы с прямым SQL, это с лихвой компенсировалось преимуществами такой изоляции. Если же это преимущество у DAL убрать, то от слоёности останутся практически одни недостатки.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>В этом случае у тебя уже нет одного ORM, а есть несколько систем, так что наличие DAL может быть оправдано. Только ты уже начинаешь выдумывать кейсы, которых раньше не было.
Т.е. этот кейс тоже не подходит? А ничего что я с самого начала утверждал, что одна из причин это независимость от ORM и хранилища, и это как раз прямая иллюстрация.
G>Если автоматически можно мапить модель на DTO, тогла модль по структуре совпадает с DTO и в ней по сути нет смысла. Иначе надо настраивать маппинг, а это тоже ручные изменения, которые надо делать параллельно с изменением схемы.
Это от задачи зависит.
Doc>>Разговор был о решаемой задаче. G>Она как-то меняется со временем. Я рассматриваю средний случай, ты все время выдумываешь corner cases.
Шикарно Ну если это выдуманная задача — смысла продолжать нет. Показывать сорцы я точно не буду. Выдуманная так выдуманная.
Doc>>Сокрытия какого функционала? G>Который ты скрываешь на основании религиозного убеждения о принадлежности того или иного функционала к конкретному слою.
И в чем проблема ситуации, когда тонкости ORM и БД скрыты от DAL. Ходим по кругу
G>Значит ты изначально что-то не так делал. G>Попробую угадать.
100% мимо. Более того, ты показал что "чучка не читатель, чукча писатель". Нет там файлов, блобов итд Все работа идет с кучей записей вида date/name/value. Кстати, вынос файлов бы никак не сэкономил бы дисковое пространство (уменьшение размеров БД в этом случае фикция, т.к. ничего не дает, а модель и без этого можно тянуть только с нужными полями).
Извините, но дальше не вижу смысла вести разговор, т.е. надоело повторять одно и тоже и видеть игнор написанного.
Здравствуйте, IT, Вы писали:
IT>Можно я приведу пример логического боснования против разбиения логики приложения на слои? Спасибо.
Сам спросил, сам ответил. Ну ясно дело, ведь приятно поговорить с умным человеком
IT>Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям.
Ух ты, это интересно, что за бизнес-процесс вклчает в себя описание как сохранять документы в БД?
IT> Что в свою очередь приводит к значительному увеличению объёма кода
Ну это как писать. Все что есть в моем DAL было бы в вашем BL (или как угодно назовите). От того, что я перестану использоваться EF в своем классе, у него не появится batch update/delete. Это кусок кода все равно будет в виде extension или просто класса в приложении. OQ так же будут в виде классов — ради из повтороного использования в том же BL.
IT> Дополнительные проблемы сюда вносит попытка повторного использования бизнес логики.
А вот это вообще ваши фантазии. Я нигде не утверждал что BL можно повторно использовать. А вот ту же обретку для EF — легко.
IT> Как привило, в размазанном по слоям коде BL соостоит более чем наполовину их мусора типа path-through методов
Опять неправда ваша.
IT> В один и тот же метод вносятся части слабо связанных друг с другом алгоритмов
"И тут Остапа понесло" "Умение" нарушать SRP вообще никак не связана с разделением по слоям. Ну и все эти ошибочные высказывания приводят вас к странным выводам. Хотя даже не выводам, а просто попытке "навешать всех собак" чтобы выглядело все это страшно.
Здравствуйте, Doc, Вы писали:
IT>>Можно я приведу пример логического боснования против разбиения логики приложения на слои? Спасибо. Doc>Сам спросил, сам ответил. Ну ясно дело, ведь приятно поговорить с умным человеком
Дык. Учись пока я жив.
IT>>Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям. Doc>Ух ты, это интересно, что за бизнес-процесс вклчает в себя описание как сохранять документы в БД?
А почему бы его не включать? Сохранение документа — это часть бизнес процесса. Можно, конечно, эти вещи искусственно разделить и гордится никому не нужными абстракциями, но вообще-то это называется over-architecture.
IT>> Что в свою очередь приводит к значительному увеличению объёма кода Doc>Ну это как писать. Все что есть в моем DAL было бы в вашем BL (или как угодно назовите). От того, что я перестану использоваться EF в своем классе, у него не появится batch update/delete. Это кусок кода все равно будет в виде extension или просто класса в приложении. OQ так же будут в виде классов — ради из повтороного использования в том же BL.
Ты не понял. К увеличению кода приводит размазывание одного алгоритма по слоям. Как минимум тебе понядобится два дополнительных метода (по одному в DAL и BL) и возможно, хотя в твоём случае абсолютно точно, дополнительные сущности типа DTO, выполняющие функции переливания из пустого в порожнее.
IT>> Дополнительные проблемы сюда вносит попытка повторного использования бизнес логики. Doc>А вот это вообще ваши фантазии. Я нигде не утверждал что BL можно повторно использовать. А вот ту же обретку для EF — легко.
Утверждал выше по ветке как аргумент в пользу необходимости DAL. А то, о чём ты говоришь не имеет никакого отношения к слоям. Просто повторно используемые модули пиши хоть обпишись.
IT>> Как привило, в размазанном по слоям коде BL соостоит более чем наполовину их мусора типа path-through методов Doc>Опять неправда ваша.
Правда-правда. Наличие path-through методов говорит о непереусложнённом и эффективном дизайне. Это часть вынужденной платы за слоёность. Если у тебя в BL каждый метод выполняет ещё что-то кроме переброски вызова в DAL, то с гарантией 90% можно утверждать, что этот код не имеет никакого отношения к самой бизнес логики. Естественно, бывает, что в BL инкапсулируется определённая логика. Но таких методов в BL не более 20%. Остальное мусор.
IT>> В один и тот же метод вносятся части слабо связанных друг с другом алгоритмов Doc>"И тут Остапа понесло" "Умение" нарушать SRP вообще никак не связана с разделением по слоям. Ну и все эти ошибочные высказывания приводят вас к странным выводам. Хотя даже не выводам, а просто попытке "навешать всех собак" чтобы выглядело все это страшно.
Уверяю тебя, всё так и есть. Так может не быть только либо в микроскопических проектах для показухи, либо в теории, а мы знаем чем теория отличается от практики.
Doc>Но все равно спасибо, т.к. улыбнуло
Давай сюда код своего проекта, вместе поржём. Уверен, найдётся там и нарушение SRP, и фантомная и хрупкая бизне логика, и переусложнённый дизайн. Хотя о последнем можно сделать вывод и без исходников, просто на основании твоих рассуждений, в которых ты почему-то очень старательно умалчиваешь какие конкретные проблемы решают те или иные твои решения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, gandjustas, Вы писали:
G>>В этом случае у тебя уже нет одного ORM, а есть несколько систем, так что наличие DAL может быть оправдано. Только ты уже начинаешь выдумывать кейсы, которых раньше не было.
Doc>Т.е. этот кейс тоже не подходит? А ничего что я с самого начала утверждал, что одна из причин это независимость от ORM и хранилища, и это как раз прямая иллюстрация.
Независимость от ORM не нужна, ORM сам достаточно хорошо абстрагирует от РСУБД и современные ORMы очень мощны. Независимость от какого-то произвольного хранилища — надо смотреть по ситуации.
G>>Если автоматически можно мапить модель на DTO, тогла модль по структуре совпадает с DTO и в ней по сути нет смысла. Иначе надо настраивать маппинг, а это тоже ручные изменения, которые надо делать параллельно с изменением схемы.
Doc>Это от задачи зависит.
Да ну? А как обеспечить автомаппинг двух сущностей если они по структуре достаточно сильно отличаются? А если не отличаются, то зачем две сущности?
Doc>>>Разговор был о решаемой задаче. G>>Она как-то меняется со временем. Я рассматриваю средний случай, ты все время выдумываешь corner cases.
Doc>Шикарно Ну если это выдуманная задача — смысла продолжать нет. Показывать сорцы я точно не буду. Выдуманная так выдуманная.
Разницы нет. Если есть конкретные условия — опиши, если нет — не выдумывай на ходу.
Doc>>>Сокрытия какого функционала? G>>Который ты скрываешь на основании религиозного убеждения о принадлежности того или иного функционала к конкретному слою.
Doc>И в чем проблема ситуации, когда тонкости ORM и БД скрыты от DAL. Ходим по кругу
ORM очень мощен, ни один самописный DAL не покроет и 10% его мощностей. То есть ты сознательно не используешь все возможности инструментов в программе. А что получаешь в замен? Легкость смены DAL? Так это подавляющему большинству не нужно.
G>>Значит ты изначально что-то не так делал. G>>Попробую угадать.
Doc>100% мимо. Более того, ты показал что "чучка не читатель, чукча писатель". Нет там файлов, блобов итд Все работа идет с кучей записей вида date/name/value. Кстати, вынос файлов бы никак не сэкономил бы дисковое пространство (уменьшение размеров БД в этом случае фикция, т.к. ничего не дает, а модель и без этого можно тянуть только с нужными полями).
Ну и что ты с этими date\name\value делаешь? С ними можно сильно по-разному работать. Хранилище у тебя где? SQL? Azure Tables? Какой-нить NoSQL движок?
Doc>Извините, но дальше не вижу смысла вести разговор, т.е. надоело повторять одно и тоже и видеть игнор написанного.
По-моему ты сам начал с абстрактного вопроса, получив ответ, противоречащий твоей религии, начал спорить.
Деталей задачи ты не описал. Так что я все еще нахожусь в той же абстракции, как в начале. Похоливарить на форуме мне не сложно.
Здравствуйте, IT, Вы писали:
IT>А почему бы его не включать? Сохранение документа — это часть бизнес процесса. Можно, конечно, эти вещи искусственно разделить и гордится никому не нужными абстракциями, но вообще-то это называется over-architecture.
А PL тоже включите в бизнес-логику?
IT>Ты не понял. К увеличению кода приводит размазывание одного алгоритма по слоям.
А зачем его размазывать? Я прекрасно обхожусь без этого.
IT>Как минимум тебе понядобится два дополнительных метода (по одному в DAL и BL)
Для чего? Можно пример (псевдокод)?
IT>и возможно, хотя в твоём случае абсолютно точно, дополнительные сущности типа DTO, выполняющие функции переливания из пустого в порожнее.
Обожаю экстрасенсов, как они рассказывают что и как есть "в твоём случае абсолютно точно" DTO в DAL мне далеко не всегда нужны.
IT>Утверждал выше по ветке как аргумент в пользу необходимости DAL.
Можно цитату, не вырванную из контекста, где я говорил о повторном использовании BL.
IT>А то, о чём ты говоришь не имеет никакого отношения к слоям. Просто повторно используемые модули пиши хоть обпишись.
Можно цитату, не вырванную из контекста, где я говорил о что повторное использование это особенность только слоев?
IT>Правда-правда. Наличие path-through методов говорит о непереусложнённом и эффективном дизайне.
Хм... написать что ли в каком-нибудь проекте пару path-through методов? А то у меня их нет, и вы опять мимо. Все обманываетесь и обманываетесь.
IT>Уверяю тебя, всё так и есть. Так может не быть только либо в микроскопических проектах для показухи, либо в теории, а мы знаем чем теория отличается от практики.
IT>Давай сюда код своего проекта, вместе поржём. Уверен, найдётся там и нарушение SRP, и фантомная и хрупкая бизне логика, и переусложнённый дизайн. Хотя о последнем можно сделать вывод и без исходников, просто на основании твоих рассуждений, в которых ты почему-то очень старательно умалчиваешь какие конкретные проблемы решают те или иные твои решения.
Столько выводов не видя кода А вы по фотографии не лечите?
Doc>Повторяю последний раз Doc>1) Независимость от хранилища (сознательно не пишу БД, т.к. есть масса других вариантов и есть задачи где можно выбирать или поддерживать разные) Doc>2) Независимость от ORM и возможность на уровне DAL. Специально подчеркиваю — DAL тут является декоратором для ORM + дополнительные функции + код настройки. Doc>3) Возможность писать BL не оглядываясь на то, как сделан DAL (равно как и PL).
Doc>PS: Цели убедить вас делать такой вариант архитектуры у меня нет. Да и вообще мы ушли от исходного вопроса очень сильно в сторону. Хотя я для себя ответ нашел.
И какой правильный ответ?
К какой области относится QueryObject — к BLL или DAL?
IT>Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям.
Это исходное неверное рассуждение.
Разбиение на слои подразумевает не разбиение алгоритма на части — алгоритм при этом вообще не изменяется.
Разбиение на слои подразумевает абстрагирование от деталей реализации алгоритма, когда реализация осуществляется на более низких уровнях.
Таким образом, разбиение на слои приводит к лучшему выражению и пониманию цельного алгоритма, путем скрытия его реализации.
Здравствуйте, es3000, Вы писали:
E>И какой правильный ответ? E>К какой области относится QueryObject — к BLL или DAL?
Если смотреть на классическую трехзвенку, то в общем случае это DAL (я вот тут всеже прихожу к мысли что Repository+Specification тут правильнее выглядят, а QO уж слишком много хочет знать).
А если со стороны Onion — однозначно Infrastructure.DataAccess
Здравствуйте, Doc, Вы писали:
E>>И какой правильный ответ? E>>К какой области относится QueryObject — к BLL или DAL? Doc>Если смотреть на классическую трехзвенку, то в общем случае это DAL (я вот тут всеже прихожу к мысли что Repository+Specification тут правильнее выглядят, а QO уж слишком много хочет знать). Doc>А если со стороны Onion — однозначно Infrastructure.DataAccess
А к чему относится GetFavouriteCustomersQuery, FindDelayedOrdersQuery, GetTopPriorityOrders?
Здравствуйте, es3000, Вы писали:
IT>>Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям.
E>Это исходное неверное рассуждение. E>Разбиение на слои подразумевает не разбиение алгоритма на части — алгоритм при этом вообще не изменяется. E>Разбиение на слои подразумевает абстрагирование от деталей реализации алгоритма, когда реализация осуществляется на более низких уровнях. E>Таким образом, разбиение на слои приводит к лучшему выражению и пониманию цельного алгоритма, путем скрытия его реализации.
Согласен, но это теория. На практике, к сожалению, получается именно так как Игорь написал
Пример: обработать все просроченные заказы. На практике просроченные заказы эффективнее искать с помощью sql в базе (настолько эффективнее, что альтернативы даже не рассматриваются). Поэтому логика поиска просроченных заказов уезжает в DAL.
QueryObject пытается решить эту проблему. Он говорит, что вот я весь из себя DAL, я знаю все про SQL, но я не DAL, я BL. Мне приходится знать про SQL потому что мои нструменты не позволяют эффективно получать данные из базы без знания SQL.
С приходом LINQ ситуация существенно изменилась (я обожаю этот инструмент). Теперь запросы к базе можно писать на том же языке (ну почти) что и всю остальную логику. Это позволяет во многих случаях заменить QueryObject на прямой select в бизнесс методе. Потому что скрывать "select o.q, o.w, o.e from orders o where o.user_id = :user" строго рекомендуется (и это простйший пример), а вот from o in Orders where o.UserId = userId уже вполне вписывается в BL.
Но, даже во времена linq QueryObject не умер. У него поменялись обязанности. Он стал тру BL (без вариантов).
Вот серия статей про подход Ayende. Мне этот подход понравился. Я его лично не использовал, но что-то в нем есть.
public override void Execute()
{
var origin = Session.Load<Location>(OriginCode);
var destination = Session.Load<Location>(DestinationCode);
var trackingId = Query(new NextTrackingIdQuery());
var routeSpecification = new RouteSpecification(origin, destination, ArrivalDeadline);
var cargo = new Cargo(trackingId, routeSpecification);
Session.Save(cargo);
Result = trackingId;
}
Этот подход нужно рассматривать в комплексе. Т.е. не вырывать Query из контекста. Весь контекст это Query, Command, Task и, главное, ифраструктура, которая позволяет это все удобно использовать.
Здравствуйте, Aikin, Вы писали:
A>А к чему относится GetFavouriteCustomersQuery, FindDelayedOrdersQuery, GetTopPriorityOrders?
Я так понимаю, что (учитывая что вы процитировали), вы хотите поспорить и сказать что в них лежит бизнес-логика? Они только знаю что и откуда взять и (если форматы БД и объекта не совпадают), то как выдать. Ну и опять же, учитывайте что все эти *Query много чего знают про хранилище, чего BLL в принципе знать не должен.
Здравствуйте, Doc, Вы писали:
A>>А к чему относится GetFavouriteCustomersQuery, FindDelayedOrdersQuery, GetTopPriorityOrders? Doc>Я так понимаю, что (учитывая что вы процитировали), вы хотите поспорить и сказать что в них лежит бизнес-логика? Они только знаю что и откуда взять и (если форматы БД и объекта не совпадают), то как выдать.
Я не хочу навязывать своего мнения. Я хочу чтобы вы задумались о роли QueryObject
Знание о том кто такой фаворитный кастомер это что? Знание о том что такое просроченный заказ? Что такое заказ высшего приоритета?
Не заставляет задуматься?
А так: фаворитный заказ -- это заказ сделанный важныйм заказчиком (+ еще определение) на сумму свыше 1000$ с доставкой в другой конец страны (+ определение)
Doc>Ну и опять же, учитывайте что все эти *Query много чего знают про хранилище, чего BLL в принципе знать не должен.
Аргумент который можно спокойно инвертировать ничего не стоит: Query много чего знают про BLL, чего DAL в принципе знать не должен
Здравствуйте, Aikin, Вы писали:
A>Я не хочу навязывать своего мнения. Я хочу чтобы вы задумались о роли QueryObject
А я уже высказал его. Вы же процирировали мое высказывание, что QueryObject сильно много хочет знать.
Но по моей логике, но больше связан с DAL, т.к. при изменении DAL придется менять
A>Не заставляет задуматься? A>А так: фаворитный заказ -- это заказ сделанный важныйм заказчиком (+ еще определение) на сумму свыше 1000$ с доставкой в другой конец страны (+ определение)
Я видел ваше сообщение, где вы сказали что QO как бы и в DAL и как бы в BLL. Собственно, с этого и начался разговор. Но поскольку в проекте нельзя быть немножко беременным, то надо куда-то его отнести. В данном случае IMHO заявка на DAL сильнее, т.к. QO использует специфику про которую BLL не в курсе вообще (формат хранения данных, спец. методы обращения к ним итд).
Doc>>Ну и опять же, учитывайте что все эти *Query много чего знают про хранилище, чего BLL в принципе знать не должен. A>Аргумент который можно спокойно инвертировать ничего не стоит: Query много чего знают про BLL, чего DAL в принципе знать не должен
Вот поэтому я и обратил внимание на Specification. Т.к. там для конкретного DAL будут определены некоторые базовые операции (искать по дате, искать по мин. цене и т.д.), которые уже BLL объединяет в выражения, представляющие саму BL (грубый пример: лучшее предложение = искать по дате "сегодня" && по мин. цене).
Тот же "фаворитный заказ" прекрасно будет составлен из 3 спецификации, каждая из которых не несет какой-либо BL: что-то вроде IsVIP(user) && PriceMoreThan(order, minPrice) && LongDistanse(source, dest, minDistance)
Здравствуйте, Doc, Вы писали:
Doc>Я видел ваше сообщение, где вы сказали что QO как бы и в DAL и как бы в BLL. Собственно, с этого и начался разговор. Но поскольку в проекте нельзя быть немножко беременным, то надо куда-то его отнести. В данном случае IMHO заявка на DAL сильнее, т.к. QO использует специфику про которую BLL не в курсе вообще (формат хранения данных, спец. методы обращения к ним итд).
Можно. Все можно. На практике можно BL писать в DAL, а sql использовать в PL. GodClass тоже имеет право на существование. Например для однразового приложения.
Doc>Вот поэтому я и обратил внимание на Specification. Т.к. там для конкретного DAL будут определены некоторые базовые операции (искать по дате, искать по мин. цене и т.д.), которые уже BLL объединяет в выражения, представляющие саму BL (грубый пример: лучшее предложение = искать по дате "сегодня" && по мин. цене).
Я не готов обсуждать эту ветку без четкого определения Specification и QueryObject. Насколько я знаю теорию, эти два термина ввели разные авторы для разных классификаций.
Doc>Тот же "фаворитный заказ" прекрасно будет составлен из 3 спецификации, каждая из которых не несет какой-либо BL: что-то вроде IsVIP(user) && PriceMoreThan(order, minPrice) && LongDistanse(source, dest, minDistance) Размазывание логики по классам. Причем от проблемы мы не избавились. IsVIP -- юзер, который потратил больше 10000$ за летние месяцы прошлого года. Или IsVIP -- юзер которыйв прошлом году привел больше 20 рефералов. LongDistanse тоже не вариант, если критерий -- разные, не соседние области (графства, субъекты федерации).
Да, можно и дальше разбивать спецификации на части, но смысл. Для "чистоты кода"? Извините, но это не аргумент.
Doc>А я уже высказал его. Вы же процирировали мое высказывание, что QueryObject сильно много хочет знать. Doc>Но по моей логике, но больше связан с DAL, т.к. при изменении DAL придется менять
Да, я на ваше мнение и ответил. Ответил "не так все просто".
Не закончил мысль.
A>Да, можно и дальше разбивать спецификации на части, но смысл. Для "чистоты кода"? Извините, но это не аргумент.
А можно сказать,что QueryObject -- "немножко беременный", т.е. относится и к DAL и BL и записать все в одном месте.
Здравствуйте, Doc, Вы писали:
IT>>А почему бы его не включать? Сохранение документа — это часть бизнес процесса. Можно, конечно, эти вещи искусственно разделить и гордится никому не нужными абстракциями, но вообще-то это называется over-architecture. Doc>А PL тоже включите в бизнес-логику?
Для PL придумано семейство паттернов MVC.
IT>>Ты не понял. К увеличению кода приводит размазывание одного алгоритма по слоям. Doc>А зачем его размазывать? Я прекрасно обхожусь без этого.
Это как? Слои есть, функционал есть, а размазывание его по слоям нет? Тогда зачем тебе слои?
IT>>Как минимум тебе понядобится два дополнительных метода (по одному в DAL и BL) Doc>Для чего? Можно пример (псевдокод)?
UI:
...
var customers = MyBusinessLogic.GetCustomers();
...
IT>>и возможно, хотя в твоём случае абсолютно точно, дополнительные сущности типа DTO, выполняющие функции переливания из пустого в порожнее. Doc>Обожаю экстрасенсов, как они рассказывают что и как есть "в твоём случае абсолютно точно" DTO в DAL мне далеко не всегда нужны.
Т.е. мы только чуть-чуть беременны? Понятно.
IT>>Утверждал выше по ветке как аргумент в пользу необходимости DAL. Doc>Можно цитату, не вырванную из контекста, где я говорил о повторном использовании BL. IT>>А то, о чём ты говоришь не имеет никакого отношения к слоям. Просто повторно используемые модули пиши хоть обпишись. Doc>Можно цитату, не вырванную из контекста, где я говорил о что повторное использование это особенность только слоев?
Посмотри выше по ветке.
IT>>Правда-правда. Наличие path-through методов говорит о непереусложнённом и эффективном дизайне. Doc>Хм... написать что ли в каком-нибудь проекте пару path-through методов? А то у меня их нет, и вы опять мимо. Все обманываетесь и обманываетесь.
У тебя их нет, потому что ты напихал в свой код ещё какого-нибудь дополнительного мусора, не имеющего отношения к бизнес логике.
IT>>Давай сюда код своего проекта, вместе поржём. Уверен, найдётся там и нарушение SRP, и фантомная и хрупкая бизне логика, и переусложнённый дизайн. Хотя о последнем можно сделать вывод и без исходников, просто на основании твоих рассуждений, в которых ты почему-то очень старательно умалчиваешь какие конкретные проблемы решают те или иные твои решения. Doc>Столько выводов не видя кода А вы по фотографии не лечите?
Так давай его сюда, не стесняйся.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, es3000, Вы писали:
IT>>Разбиение логики приложения на слои приводит к разбиению цельного алгоритма на части и размазыванию его по слоям. E>Это исходное неверное рассуждение.
Видимо всё же это исходное непонятое рассуждение.
E>Разбиение на слои подразумевает не разбиение алгоритма на части — алгоритм при этом вообще не изменяется.
Может и не меняется, но расслаивается, т.е. разбивается на части.
E>Разбиение на слои подразумевает абстрагирование от деталей реализации алгоритма, когда реализация осуществляется на более низких уровнях.
Зачем мне абстрагироваться от деталей, которых нет?
E>Таким образом, разбиение на слои приводит к лучшему выражению и пониманию цельного алгоритма, путем скрытия его реализации.
Относительно к нашей дискуссии, это справедливо если в DAL используется прямой SQL. Если используется Linq, то расслоение не даёт никаких выгод, я вот все проблемы расслоения мы получаем автоматически.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Aikin, Вы писали:
A>Можно. Все можно. На практике можно BL писать в DAL, а sql использовать в PL. GodClass тоже имеет право на существование. Например для однразового приложения.
... или для проверки какой-нибудь идеи итд Но я о продакшене. А там такое поддерживать как-то не хочется.
A>Я не готов обсуждать эту ветку без четкого определения Specification и QueryObject. Насколько я знаю теорию, эти два термина ввели разные авторы для разных классификаций.
Давайте ваш вариант определения.
A>Да, можно и дальше разбивать спецификации на части, но смысл. Для "чистоты кода"? Извините, но это не аргумент.
На мой взгляд нет тут размазывания логики. Тогда и +-/* то тоже размазывание логики. Под IsVIP я как-то про статус подумал. Согласен, вы говорили про $1000, тогда что-то вроде IsUserSummary(user) > 1000. Но я думаю вы идею поняли.
Насчет размывания, тоже не согласен. Спецификации по сути это небольшие операции, которые знают где взять данные. Незнаю, ясно ли выражусь, но если абстрагироваться, то это своего рода маппинг бизнес-объектов на хранилище. Т.е. BL используя ту или иную спецификацию говорит что "дай юзера", "дай цену не меньше N" и т.д. Т.е. самой BL в отдельном "дай" нет, но спецификация знает откуда взять и их можно логически объединять (вот это уже на BL уровне).
A>Да, я на ваше мнение и ответил. Ответил "не так все просто".
Здравствуйте, Aikin, Вы писали:
A>>Да, можно и дальше разбивать спецификации на части, но смысл. Для "чистоты кода"? Извините, но это не аргумент. A>А можно сказать,что QueryObject -- "немножко беременный", т.е. относится и к DAL и BL и записать все в одном месте.
Если нам не помогут, то мы тоже никого не пощадим.
Ну если это выдуманная задача — смысла продолжать нет. Показывать сорцы я точно не буду. Выдуманная так выдуманная.
Размазывание логики по классам. Причем от проблемы мы не избавились. IsVIP -- юзер, который потратил больше 10000$ за летние месяцы прошлого года. Или IsVIP -- юзер которыйв прошлом году привел больше 20 рефералов. LongDistanse тоже не вариант, если критерий -- разные, не соседние области (графства, субъекты федерации).
