В какой момент архитектура должна стать многоуровневой? - PullRequest
4 голосов
/ 22 июля 2009

Очевидно, что «Hello World» не требует отдельного модульного интерфейса и интерфейса. Но любой проект уровня предприятия делает.

Предполагая некоторый спектр между этими точками, на каком этапе приложение должно быть (концептуально или на уровне проектирования) многоуровневым? Когда вводится база данных или какой-то внешний ресурс? Когда вы обнаружите, что вы ожидаете спагетти-код в ваших методах / функциях?

Ответы [ 9 ]

7 голосов
/ 22 июля 2009

при вводе базы данных или какого-либо внешнего ресурса.

но также:

всегда (кроме самых тривиальных приложений) отдельный уровень представления AT LEAST и уровень приложения

см

http://en.wikipedia.org/wiki/Multitier_architecture

3 голосов
/ 22 июля 2009

Слои - это способ сохранить дизайн слабо связанным и очень сплоченным .

Когда вы начинаете иметь несколько классов (реализованных или просто зарисованных с помощью UML), они могут быть логически сгруппированы в слои - или, в более общем случае, в пакеты или модули. Это называется искусством разделения интересов .

Чем раньше, тем лучше: если вы не начнете наслаивать достаточно рано, то вы рискуете никогда не делать этого, поскольку усилия могут быть слишком важными.

2 голосов
/ 22 июля 2009

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

Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения

Шаблоны корпоративной архитектуры приложений

Некоторые другие книги, которые я настоятельно рекомендую:

Прагматичный программист: от подмастерье до мастера

Рефакторинг: улучшение дизайна существующего кода

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

2 голосов
/ 22 июля 2009

Вот несколько критериев, когда ...

  1. В любое время, когда вы ожидаете заменить одну часть этого с другая часть.
  2. В любое время вы найдете вам нужно разделить работу между параллельная команда.
1 голос
/ 22 июля 2009

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

И в действительно хорошо разработанном приложении коробки становятся очень маленькими. Они находятся на уровне отдельных интерфейсов и классов.

Это важно, потому что всякий раз, когда вы меняете строку кода, вы должны иметь некоторое представление о том, какое влияние окажут ваши изменения, а это означает, что вы должны точно понимать, что код делает в данный момент, каковы его обязанности, что означает должен быть небольшой блок с единственной ответственностью, реализующий интерфейс, который не заставляет клиентов зависеть от того, что им не нужно (S и I SOLID).

Вы можете обнаружить, что ваше приложение может выглядеть так, как будто оно имеет два или три простых слоя, если вы сузите глаза, но это не так. Это на самом деле не проблема. Конечно, катастрофически плохо спроектированное приложение может выглядеть так, будто оно имеет уровни слоев, если вы щуритесь так сильно, как только можете. Таким образом, эти «высокоуровневые» диаграммы «архитектуры» могут скрывать множество грехов.

1 голос
/ 22 июля 2009

Я думаю, что как только вы спросите себя: «Хм, я должен наслоить это», ответ - да.

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

Прагматичный программист перечисляет это как теорию разбитого окна.

Попробуйте и всегда делайте это с самого начала. Разделите ваши проблемы. Постройте его с учетом модульности.

И, конечно, попробуйте подумать о плохом программисте, который может поработать, когда вы закончите!

1 голос
/ 22 июля 2009

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

Это не отменяет сценарии, которые уже были выделены другими.

0 голосов
/ 22 июля 2009

Свободная связь - это все о минимизации зависимостей, поэтому я бы сказал «слой», когда вводится зависимость. то есть база данных, стороннее приложение и т. д.

Хотя «слой» в наши дни, вероятно, неправильный термин. Большую часть времени я использую Dependency Injection (DI) через контейнер Inversion of Control, такой как Castle Windsor. Это означает, что я могу кодировать в одной части моей системы, не беспокоясь об остальных. У этого есть побочный эффект обеспечения слабой связи.

Я бы все время рекомендовал DI в качестве общего принципа программирования, чтобы у вас был выбор, как «наслоить» ваше приложение позже.

Посмотри.

R

0 голосов
/ 22 июля 2009

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

(или как первый ответ, по крайней мере, уровень представления и уровень приложения).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...