Правила для добавления ссылок между проектами C #?

Question

У меня вопрос по ссылкам между проектами в решении. Большинство моих предыдущих приложений только что имели один или два проекта в решении, но на этот раз я хочу разделить приложение дальше.

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

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

Существуют ли какие-либо правила / советы / шаблоны, которые я должен учитывать при создании различных проектов и их объединении?

Должен ли я начать изнутри и выйти? Наличие «основных» проектов отражает все внешние проекты или, возможно, идет извне и где все независимые проекты ссылаются на «основные»? Или третий вариант, когда у меня есть бизнес в двух проектах, и оба они ссылаются на третий проект?

Answer 1

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

Обычно, прежде чем я даже открываю Visual Studio, я беру лист бумаги и делю свою проблему на логические функциональные области. Вы можете нарисовать сборку Utilities вверху, а все графические интерфейсы, веб-сервисы и другие конечные проекты внизу. Проект Utilities не будет ссылаться ни на какой другой проект, и на те, что внизу, ничего не будет ссылаться. Затем вы думаете, какие функции являются общими для них, например, все графические интерфейсы могут совместно использовать общий проект пользовательского интерфейса с общими пользовательскими элементами управления и диалоговыми окнами, и этот проект пользовательского интерфейса будет ссылаться на проект «объектной модели» и т. д. Проект в нижней части может ссылаться только на то, что находится над ними.

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

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

Answer 2

Это немного старомодно, но для помощи в принятии решения о том, как разделить на проекты, вы можете посмотреть "Соединение" и "Сплоченность" в Википедии.

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

1. Компилятор C # понимает ключевое слово "internal". Чтобы принимать лучшие решения о факторинге в отдельные проекты, вы должны действительно понимать всю силу этого.

2. JIT-компилятор во время выполнения никогда не встроит вызов функции, который пересекает границу сборки, что влияет на производительность. (Причина в безопасности доступа к коду).

Есть еще много примеров, поэтому решение действительно имеет значение.

Answer 3

Я буду использовать приложения Winforms в качестве примера. Шаблон, в который я начал проникать, таков. Решение называется Пример.

Example.Entities - Этот проект будет содержать мои бизнес-объекты и связанную иерархию классов

Example.Dal - Я помещаю всю бизнес-логику и логику доступа к данным в этот проект (пространство имен). Этот код загружает ваши бизнес-объекты и затем передает их на другой уровень.

Example.Gui - Я разместил здесь все свои утилиты Winforms и GUI и мой основной метод начального ввода. Вы также можете просто назвать этот проект Примером. Мне все еще нравится использовать пространство имен Example.Gui для разделения кода.

Example.Test - Вы можете поместить весь свой тестовый код в этот проект.

Я пытаюсь ввести код в Entities , если он принадлежит одному из бизнес-объектов или коллекции бизнес-объектов.

Gui будет ссылаться на сущности и Dal (уровень доступа к данным). В зависимости от того, как вы пишете свой Dal, он может ссылаться на ваши сущности. Тест должен ссылаться на Entities, Dal и, возможно, Gui.

Entities - это собственный сборочный dll, чтобы вы могли использовать его в других проектах. Или верните их из службы .NET SOAP.

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