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

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

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

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

Вы проекты "чистые" или отказались от идеи сохранить четкую линию между слоями давным-давно? Если вы все еще держите это правильно, как вы относитесь к коллегам, которые не понимают этих вещей или не заботятся о том, чтобы они просто строили "пользовательские" решения и хакерские хаки все время? Или в какой-то момент вы перестали сражаться с ветряной мельницей и приняли ее как свое наказание? EDIT: Несколько удивил, что не многие люди заинтересовались проблемой. Значит ли это, что больше всего не важно?

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Проект ASP.NET содержит около 100 страниц .aspx.

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

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

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

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

Итак, короче, 100% чистый. Это просто всегда было лучше, чтобы сделать это правильно.

Мы должны иметь чертовски вескую причину, чтобы отойти от этого сейчас.

Ответ 5

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

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

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

Ответ 6

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

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

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