Насколько строго вы следуете n-уровневой архитектуре и разделению проблем между уровнями в ваших проектах?
Я предполагаю, что большинство разработчиков имеют представление о многослойной архитектуре. У нас есть DAL (уровень доступа к данным), у нас есть BLL (уровень бизнес-логики), и где-то ближе к концу пути у нас есть наш пользовательский интерфейс. Если у вас есть проект, который каким-то образом следует этим принципам, продолжаете ли вы (или хотя бы пытаетесь) оставить / поместить вещи там, где они концептуально принадлежат? Меня особенно интересуют приложения для больших компаний, где вы работаете вместе со многими другими людьми. Очевидно, что вы можете делать все, что захотите, с вашим собственным игрушечным проектом, изобретать любую архитектуру и придерживаться ее. Это не так просто с большими проектами, где много людей вносят свой вклад в программное обеспечение или общий беспорядок.
Например, мне довелось увидеть такие вещи, как компоненты пользовательского интерфейса, идущие непосредственно в базу данных для извлечения некоторых "отсутствующих" дополнительных данных, которые BL не предоставляет, а также UI и BL, работающие с элементами низкого уровня, такими как поля таблицы, где, по моему мнению, они должны делегировать эти операции на нижнем уровне, а именно DAL. Это было особенно грустно, когда после обсуждения вещей со старшим разработчиком я увидел, что он вообще не видит проблемы с этим.
Конечно, мы можем предположить, что я и тот, кто разделяет мою точку зрения, просто перфекционисты, но я ясно увидел очень неблагоприятное последствие в том, что мне потребовалось много времени для выполнения моих задач, чтобы отследить все "параллельные" маршруты, которые данные перемещаются в базу данных и из нее, чтобы определить, на кого и каким образом теперь может повлиять новая реализованная мной функциональность. На мой взгляд, это увеличение затрат на дальнейшую разработку / обслуживание, перевешивающее некоторую экономию, когда кто-то решил быстро взломать материал и закрыть задачу как можно скорее.
Вы проекты "чистые" или они давно отказались от идеи держать четкую грань между слоями? Если вы все еще держите это правильно, как вы справляетесь с коллегами, которые не понимают этих вещей или не заботятся о них, просто создавая "нестандартные" решения и постоянно взламывая хаки? Или в какой-то момент вы перестали сражаться с ветряной мельницей и приняли это как наказание? РЕДАКТИРОВАТЬ: Несколько удивлен, что не многие люди заинтересовались этой проблемой. Это знак больше всего пофиг?
6 ответов
Чем сложнее становится наше приложение, тем важнее становится разделение интересов.
При 100 klocs приложение представляло собой один большой двоичный объект: столько же бизнес-кода в классах форм, сколько где-либо еще, и вызовы методов форм из бизнес-классов. С большим воплем и скрежетом зубов мы отделили бизнес-логику от логики дисплея. Любой класс, которому нужно было уведомить пользователя о своем прогрессе, вызывал событие, потопленное пользовательским интерфейсом. И какое-то время все было хорошо с миром.
Приблизительно в 200 клоках мы добавили слой данных. Архитектура нашего приложения была такова, что большая часть наших данных была обработана, как только она поступила, и сразу же была отброшена. Большая часть информации о конфигурации хранилась в стороннем приложении, с которым у нас были симбиотические отношения. Но настройки начали накапливаться во всевозможных странных углах. Мы получили три системы управления конфигурацией, все они запутаны в бизнес-логике. Благодаря обширной переписке мы смогли разделить информацию о конфигурации на свой собственный уровень и обработать потоковую передачу данных на другой уровень.
Рядом с линией 250 кЛОк мы решили прекратить наши отношения со сторонним поставщиком и сделать наше приложение автономным. Мы начали массовую переписку и впервые добавили актуальную базу данных в наше приложение. Поскольку у нас были четкие границы между потоковой информацией, хранением данных и бизнес-логикой, это была довольно плавная интеграция.
Теперь, приближаясь к 500 клокам, мы переводим приложение на сеточную архитектуру. Мало того, что пользовательский интерфейс будет отделен от бизнес-логики на другом компьютере, фактическое вычисление котировок и заказов, которые отправляет приложение, будет сбалансировано по нагрузке и распределено для максимизации эффективности. Это было бы невозможно без n-уровневой архитектуры.
На каждом этапе роста нам либо помогало четкое разделение, либо препятствовали наши собственные проблемы с коммуникацией, данными, бизнесом и пользовательским интерфейсом. Вероятно, не было более важной проблемы, чем это разделение при создании этого приложения.
Это отличный вопрос! Что-то, о чем должен думать каждый разработчик ASP.Net. Вы, вероятно, получите много ответов, я бы поддержал эти основные идеи здравого смысла.
- Учитывайте простоту и скорость доставки как часть "успешной" архитектуры, а не просто "чистоты". Попробуйте балансировать между соблюдением архитектурных идеалов и практичностью.
- В общем, кажется, что имеет смысл разделить код на слои, как вы упомянули. Я хотел бы предложить, однако, что для специфичной для страницы логики ее можно оставить на странице, если она проще / быстрее - зачем создавать общие бизнес-объекты для кода, который просто используется в одном месте. Как уже было сказано, "Преждевременная оптимизация - корень всего зла".
- Сохраняйте уровни и сложность до минимума, чтобы сократить время кодирования и улучшить удобочитаемость и ремонтопригодность.
На этом сайте есть много пуристов, которые любят создавать архитектуру для архитектурного сайта - использовать архитектуру как инструмент для решения бизнес-проблемы, а не просто как художественную форму для себя, пусть это будет скорее полезный инструмент чем он использует тебя.
Держите проблемы отдельно. Это очень очень важно. Не смешивайте пользовательский интерфейс с Biz и Biz с уровнем данных. Работа с абстракцией. Работа с абстракцией также облегчает тестирование (модульное тестирование) (Насмехайтесь над ними). Я строго держу каждый слой там, где он принадлежит. Помните, что самая высокая стоимость в любом проекте - это его сопровождение. Если вы смешаете проблемы, то обслуживание станет кошмаром.
У нас есть приложение Winforms и приложение ASP.NET. Они оба используют один и тот же проект Business Objects (около 140 классов).
Проект Winforms состоит из около 350 форм и классов управления пользователями, и очень немногим (<10) из них нужны метаданные о себе из базы данных.
Проект ASP.NET имеет около 100 страниц ASPX.
У нас есть уровень доступа к данным, состоящий из 5 классов, которые связаны с ADO.NET, потоками и транзакциями. Они преобразуют запросы от бизнес-объектов в вызовы SQL Server.
Слои пользовательского интерфейса (за исключением нескольких классов, которым нужны метаданные о размерах форм) вообще не имеют доступа к базе данных. Даже несколько исключений проходят через DAL, как и все остальное.
Бизнес-уровень ничего не знает о внутренней работе уровня доступа к данным, а когда ему нужны данные, он вызывает только открытые методы для классов DAL.
Я не являюсь фундаменталистом, когда дело доходит до такого рода вещей, но нам никогда не приходилось сокращать этот вопрос.
Короче говоря, 100% чистота. Просто всегда получается лучше сделать это правильно.
У нас была бы чертовская веская причина, чтобы отойти от этого сейчас.
Code Monkeys and Purists во многом похожи на любого другого экстремиста в жизни.
У нас крайнее правое крыло и крайнее левое крыло. Очень немногие люди точно так или иначе, и они находят хорошую середину, где они сидят. Если бы не экстремисты, мы бы не знали, где лежат границы.
Насколько я пишу код. Я слушаю пуристов, как это сделать. Я вижу код обезьян, идущих по поводу своих методов. Я использую свой опыт, чтобы выбрать золотую середину, которая дает мне необходимую гибкость и управляемость, а также время, необходимое для его производства, и сумму денег, которую я фактически собираюсь получить за это.
Чем больше код, тем дольше время жизни, чем больше людей работают над кодом (одновременно или в течение жизни), тем важнее разделение по слоям. В начале это кажется немного более ненужной работой, но в конечном итоге это окупается в несколько раз.
Что касается принудительного разделения: вот почему вашему ведущему программисту или техническому архитектору нужны хорошие навыки работы с программным обеспечением, а также чисто технические навыки. Вы можете попытаться обеспечить разделение технически (см. Ниже), но, в конце концов, вам нужно убедить (или принудить) ваших разработчиков сохранить чистую картину в целом.
Но это не значит, что технические средства для обеспечения разделения не имеют смысла. Фактически, я обнаружил, что обеспечение того, что "трансграничные звонки" несколько затрудняют выполнение, заставит людей тратить больше времени на размышления о том, что им действительно нужно в трансграничном интерфейсе, что приводит к более чистым интерфейсам. Неважно, техническая проблема (потому что вы должны использовать COM или CORBA) или что-то еще (вы должны заполнить 7-страничную форму в трех экземплярах).