Разделение сборок в многоуровневой архитектуре

Question

Я проверил перед публикацией, поэтому, если это дуп, я извиняюсь.

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

Company.Project.Presentation.Core - эта сборка содержит все контракты / интерфейсы для представлений и докладчиков

Company.Project.Presentation.WinForms - эта сборка содержит конкретные реализации представлений и докладчиков.

Основная причина, по которой я решил сделать это, заключалась в том, что, если мы решим перейти на WPF, контракты будут независимыми.сборка.

Кажется ли это хорошей идеей?или я просто увеличиваю количество проектов в своем решении, когда одной сборки с подпапками / пространствами имен будет достаточно?

Спасибо за любой предварительный вклад,

Jeremie

Answer 1

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

Пока все хорошо :) 1003 *

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

Я просто увеличиваю количество проектов в своем решении, когда одной сборки с подпапками / пространствами имен будет достаточно?

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

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

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