"В бизнес логике выделяем слой интерфейсов. Объявление отделяем от имплементации. Вводим фабрику интерфейсов. Назначение конкретной имплементации описываем в специальной секции конфигурационного файла."
Вполне здравые идеи, и звучат убедительно, как будто кто-то гвозди в доску забивает. Малую малость упустили из виду - "А зачем это все?" Смотрим в исходники проекта, и видим что? Для каждого интерфейса на весь проект только одна реализация, альтернатив нет и не предвидилось. "Специальная секция конфигурационного файла" не разу не изменялась с момента своего создания. Так и зачем огород городить было?
Или другой пример. Надо построить квартальный отчет по продажам, и для этого используем класс Sale, экземпляры которого, представляют продажи в бизнес логике приложения. За квартал набегает пара десятков тысяч продаж, и естественно, сервер приложений ложится на вычислении квартального отчета. Хранимая процедура в БД справилась бы с этой работой за несколько секунд, но "архитектура системы запрещает обращения к БД из слоя бизнес логики". К счастью догматы архитектурной веры позволили создать в системе бизнес объект "Квартальный отчет по продажам", который по всем архитектурным правилам, посредством DAL, и с прочими приседаниями, получил данные из шустрой хранимой процедуры, и таким образом, весь сервер приложений был спасен от неминуемой гибели.
Мораль. Не давайте шаблонам управлять своими мозгами. Должно быть все наоборот. Оставайтесь в меру беспринципными, когда это может пойти на пользу делу. И главное: "Do simplest thing that could possibly work" (с)К. Бек.
10 комментариев:
"Смотрим в исходники проекта, и видим что? Для каждого интерфейса на весь проект только одна реализация, альтернатив нет и не предвидилось."
Традиционное решение проблем, которые скорее всего никогда не возникнут. А слой абстракции от БД у вас предусмотрен? Ну на тот случай если придется преходить с MsSql на Oracle? :)
Явление описанное вами давно имеет название - дизайнэнурез или недержание креатива.
>"недержание креатива"
Это надо запомнить. :)
шаблоны тут не причем
просто надо кроме шаблонов еще и мозги использовать
с основной идеей согласен - нехорошо быть в плену, даже у правильных идей :)
по поводу обложиться интерфейсами - это ведь хорошо для юнит-тестирования (моки, фэйки, стабы и т.п.)
видимо, тут можно придумать какое-то мнемоническое правило насчёт интерфейсов - обложиться интерфейсами, но не облажаться :)
keep it simple stupid :)
Но ведь лучше, когда выделенный слой, когда все обложено интерфейсами, ведь когда возникла проблема, мы можем в конкретном месте, в конкретное время, обойти какой-нибудь слой, повесить атрибут [PerfomanceHack] и сервер приложений снова оживает, а вот если у нас на самой странице, код в PageLoad() создает конекшен, потом ломится в базу и так во всем приложениее :), то тут все гораздо сложнее. Правильно написанную программу гораздо легче оптимизировать при необходимости, чем криво написанную.
> Но ведь лучше, когда выделенный слой, когда все обложено интерфейсами
Любое пректное решение должно приниматься осмысленно. Мы привыкаем "выделять слой доступа к данным, слой бизнес логики..." и т.д. просто потому, что делаем это всегда. А ведь это - проектные решения, и они были в свое время придуманы для решения совершенно определенных проблем и задач. Всегда сказав "а", говори "б". Сказав "мы выделяем слой ...", говори самому себе "для того, чтобы...".
Сначала необходимо написать юнит тест на функционал, которые попытаетесь разработать, и сразу станет ясно для чего использовать слои интерфейсы и т.д.
Судя по всему, мало кто понимает, для чего же нужна эта волокита с интерфейсами, слоями и шаблонами. А нужна она для того, чтобы поддерживать балланс между связностью и зацеплением компонентов. Необходимо обеспечить гибкость сохранив простоту. Все это необходимо для того, чтобы облегчить разработку. ОБЛЕГЧИТЬ! А не запутать и не затруднить. Поэтому каждый интерфейс, который был реализован только один раз - это очередной гвоздик в крышку гроба проекта. Когда их единицы, это не страшно. Но когда их десятки, то на код можно смело вешать атрибут [kg/am].
http://alamar.livejournal.com/178410.html
Проблема, на самом деле, возникает не от излишне правильного разделения слоёв, а оттого, что когда в руке один большой молоток, шурупы и саморезы имеют все шансы быть забитыми.
А именно: у программистов корпоративных систем есть привычка всё писать на одном языке, не считая XML. То есть, на Java/C#.
Что неизбежно приводит к манипулированию ста тысячами объектов по полтора поля в каждом вместо одного SQL-запроса. Иначе на этих языках не напишешь.
На самом же деле, бизнес-логику писать надо на некотором миниязыке, который будет предназначен именно для манипулирования массой бизнес-объектов. Этот язык будет позволять описать то же построение квартального отчета в десять раз короче.
И, самое важное, этот язык будет одинаково прозрачно компилироваться хоть в Java+EJB, хоть в PL/SQL. Из одного и того же исходника. При этом будучи языком высокого уровня и работая исключительно на уровне бизнес-объектов.
ну вот, сами Люксы (известные как Великие Собеседователи) себе противоречат.
сейчас ни одного собеса не пройдешь, не зная, что такое паттерны да путанные наследования и интерфейсы а куда работать ни придешь, где код ни глянешь - везде этого нет, либо есть, но в очень ограниченном количестве. либо, как првавильно тут сказано, этим пожертвовано во имя производительности.
вот реально, где, в каком корпоративном приложении используются все эти Айоки, ТДД, моки, распределения обязанностей?
стандартно, в офисных приложениях, зачастую используется наследование методом копи-паста. и оно оправдано, ибо быстрее и эффективнее.
вся эта бредятина про расширяемость, масштабируемость и тестабильность упирается в простые реалии - код, написанный таким способом, масштабируется гораздо хуже. ибо затраты на поддержание псевдомасштабируемости будут тупо больше, чем затраты на простое переписывание зависимых компонентов.
опять же оговорюсь - в большинстве случаев. разумеется, есть такие фрагменты и компоненты систем, где это все применяется. но применять надо по делу, а то получится стрельба из пушки по воробьям.
но к сожалению, Великие Собеседователи остаются непреклонны - умеете ли стрелять из пушки по воробьям? ах, не умеете? фоулера и александреску по ночам не читаете? ах, умели когда-то но теперь забыли? или теоретически знали, но не применяли? фтопку, значит вы ваще работать не умеете и непонятно, как до сих пор работали.
Отправить комментарий