Каким стандартам следует следовать для организации решения?

Question

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

Мне было интересно, есть ли какие-то отраслевые стандарты, которым я должен следовать, чтобы разбить решение на отдельные проекты / решения. Должен ли я просто сохранить все эти формы как часть корневого решения?

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

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

У меня недостаточно высокой репутации для публикации изображений, но текущая организация имеет все формы на корневом уровне решения и представляет собой просто список их в алфавитном порядке (как и следовало ожидать), например: frmAddEquipment , frmAssignSoftware, frmBackupReports, frmContacts и т. д., и т. д.

Answer 1

Даже в настольном приложении у вас должны быть слои. Разделение приложения на доступ к данным, бизнес-логику и уровни представления наложит на ваше приложение структурные и архитектурные ограничения, которые повысят возможности повторного использования, поддержки и тестирования.

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

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

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