Проблема с зависимостью проекта Asp.net (Создание каждого уровня отдельно)

Question

Project1 = Проект страниц Asp.net (Уровень представления)

Project2 = Уровень доступа к данным

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

Я сделал выше, но новые методы не были вызваны. (Я думаю, что Project1 все еще указывает на старые сборки Project2)

Я уверен, что если я пересоберу Project1, изменения будут работать.

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

Answer 1

Вам НЕ нужно его перестраивать.Вы можете просто скопировать новый dll project2 в каталог web app \ bin, и он будет работать, если интерфейс не изменился.Сборка проекта 1 будет избыточно перестраивать проект 1 и давать тот же результат, а также включать последнюю версию проекта 2, поэтому она тоже работает.

Answer 2

Прежде всего, отдельный уровень на самом деле не означает отдельных сборок. Многоуровневая программа архитектуры может быть легко сохранена в одной сборке и иметь DAL, презентацию и классы BL, разделенные некоторым логическим разделителем, таким как пространство имен или даже папки проекта с классами (или даже без логического разделения, но вы будете знать, что определенный набор классов для DAl и для BL и т. д.)

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