Как начать с разработки класса для корпоративного приложения?


Как я могу начать с проектирования класса перед началом разработки большого приложения (как WinForm, так и WebApp). Каковы начальные "будьте осторожны" вещи, которые я должен проверить перед проектированием структур классов?

Как определить использование интерфейсов, абстрактных классов, делегатов, событий и т. д. В моем дизайне приложения?

3 4

3 ответа:

Полный ответ на этот вопрос потребует книги, а не сообщения StackOverflow! На самом деле, уже есть немало книг об этом, таких как книга Мартина Фаулера Шаблоны архитектуры корпоративных приложений. Вот некоторые общие указания:

  • Убедитесь, что вы понимаете ту часть проблемной области, над которой работаете. Вы говорили со своими клиентами, чтобы они сначала все проверили? Соответствует ли ваша модель домена тому, как они думают о мир?

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

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

  • Код для интерфейса, а не реализация. Если несколько классов все делают что-то подобное, создайте интерфейс. Не используйте абстрактные базовые классы в качестве псевдоинтерфейсов. Зависите от интерфейса и передавайте его по кругу вместо отдельных реализующих классов.

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

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

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

  • Наконец, все в меру. Доводить все вышесказанное (или вообще что-либо) до крайности-плохая идея. Единственное, что вы действительно должны делать в крайнем случае, это сама умеренность! :)

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

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

Я вижу два основных вида проектной деятельности.

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

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

Далее рассмотрим элементы бизнес-логики. Интерфейсы и абстрактные классы и т.д. являются методы структурирования реализации сложности. Разделите код так, чтобы детали были скрыты, а гибкость включена. Я рассматриваю это как упражнение по дизайну ОО, об этом есть много книг, например head first.