Насколько строго вы придерживаетесь n-уровневой архитектуры и разделения проблем между уровнями в ваших проектах?

Question

Полагаю, большинство разработчиков имеют представление о многослойной архитектуре. У нас есть DAL (уровень доступа к данным), у нас есть BLL (уровень бизнес-логики), и где-то ближе к концу пути у нас есть наш пользовательский интерфейс. Если у вас есть проект, который каким-то образом следует этим принципам, продолжаете ли вы (или хотя бы пытаетесь) оставить / поместить вещи там, где они концептуально принадлежат? Меня особенно интересуют приложения для больших компаний, где вы работаете вместе со многими другими людьми. Очевидно, что вы можете делать все, что захотите, с вашим собственным игрушечным проектом, изобретать любую архитектуру и придерживаться ее. Это не так просто с большими проектами, в которых много людей участвовали в разработке программного обеспечения или в общем беспорядке.

Например, мне довелось увидеть такие вещи, как компоненты пользовательского интерфейса, идущие непосредственно в базу данных для извлечения некоторых «отсутствующих» дополнительных данных, которые BL не предоставляет, а также UI и BL, работающие с элементами низкого уровня, такими как поля таблицы, где, по моему мнению, они должны делегировать эти операции более низкому уровню, а именно DAL. Было особенно грустно, когда после обсуждения этого вопроса со старшим разработчиком я увидел, что он вообще не видит проблемы с этим.

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

Являетесь ли вы проектами "чистыми" или они давно отказались от идеи держать четкую границу между слоями? Если вы все еще держите это правильно, как вы справляетесь с коллегами, которые не понимают этих вещей или не заботятся о них, просто создавая «нестандартные» решения и постоянно взламывая хаки? Или в какой-то момент вы перестали сражаться с ветряной мельницей и приняли это как свое наказание? РЕДАКТИРОВАТЬ: Несколько удивлен, что не многие люди заинтересовались этой проблемой. Это знак больше всего пофиг?

Answer 1

Чем сложнее наше приложение, тем важнее становится разделение интересов.

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

Приблизительно в 200 клоках мы добавили слой данных. Архитектура нашего приложения была такова, что большая часть наших данных была обработана, как только она поступила, и сразу же была отброшена. Большая часть информации о конфигурации была сохранена в стороннем приложении, с которым у нас были симбиотические отношения. Но настройки начали накапливаться во всевозможных странных углах. Мы получили три системы управления конфигурацией, все они запутаны в бизнес-логике. Благодаря обширной переписке мы смогли разделить информацию о конфигурации на свой собственный уровень и обработать потоковые данные на другом уровне.

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

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

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

Answer 2

Это отличный вопрос! Что-то, о чем должен думать каждый разработчик ASP.Net. Вы, вероятно, получите много ответов, я бы поддержал эти основные идеи здравого смысла.

- Рассматривайте простоту и скорость доставки как часть «успешной» архитектуры, а не только «чистоты». Попробуйте балансировать между соблюдением архитектурных идеалов и практичностью.

- В общем, кажется, что имеет смысл разделить код на слои, как вы упомянули. Я хотел бы предложить, однако, что для логики, специфичной для страницы, ее можно оставить на странице, если она проще / быстрее - зачем создавать общие бизнес-объекты для кода, который просто используется в одном месте. Как уже было сказано, «Преждевременная оптимизация - корень всего зла».

- Сократите уровни и сложность до минимума, чтобы сократить время кодирования и улучшить удобочитаемость и удобство обслуживания.

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

Answer 3

У нас есть приложение Winforms и приложение ASP.NET. Они оба используют один и тот же проект Business Objects (около 140 классов).

Проект Winforms состоит из около 350 форм и классов управления пользователями, и очень немногим (<10) из них нужны метаданные о себе из базы данных. </p>

Проект ASP.NET имеет около 100 страниц ASPX.

У нас есть уровень доступа к данным, состоящий из 5 классов, которые связаны с ADO.NET, потоками и транзакциями. Они преобразуют запросы от бизнес-объектов в вызовы SQL Server.

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

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

Я совсем не фундаменталист, когда дело доходит до такого рода вещей, но нам никогда не приходилось обрезать это.

Короче говоря, 100% чистота. Просто всегда лучше сделать это правильно.

У нас должна быть адская веская причина, чтобы отойти от этого сейчас.

Answer 4

Держите проблемы отдельно. Это очень очень важно. Не смешивайте пользовательский интерфейс с Biz и Biz с уровнем данных. Работа с абстракцией. Работа с абстракцией также облегчает тестирование (модульное тестирование) (Насмехайтесь над ними). Я строго держу каждый слой там, где он принадлежит. Помните, что самая высокая стоимость в любом проекте - это его обслуживание. Если вы смешаете проблемы, то обслуживание станет кошмаром.

Answer 5

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

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

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

Answer 6

Код Обезьяны и пуристы во многом похожи на любого другого экстремиста в жизни.

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

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