WCF N-Tier Architecture

Question

Я работаю над довольно простым многоуровневым приложением (WPF, WCF, EF 4 и SQL).Что касается архитектуры, то мы планировали включить один «общий» проект, который будет включать как объекты, так и контракты на обслуживание.

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

Мне интересно услышать мнение других.

Спасибо!

Answer 1

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

Я бы порекомендовал вам держать доступ к данным и договорам на обслуживание по этой причине.

Answer 2

Наличие контрактов в отдельной сборке дает вам возможность внедрять разные объекты в другой сборке, предоставляя сборку контрактов разработчику, и он реализует его и дает вам dll, который вы можете поместить в папку проекта и добавьте в нее IoC-фреймворк, например StructureMap, без перестройки,

с контрактами в той же сборке, которая содержит сущности, связывают контракты с реализациями ...

Answer 3

Именно так я структурировал дизайн для приложения n-уровня электронной коммерции, которое я разработал.

Существует две общие библиотеки - одна для DTO и другая для интерфейсов.

Затем клиент и сервер включили эти библиотеки, и сервисные прокси были сгенерированы с использованием общих типов.

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

У меня также было служебное приложение, которое содержало все необходимое для работы вспомогательного типа.

РЕДАКТИРОВАТЬ: Извините, просто перечитайте ваш вопрос. В моем случае у меня было несколько библиотек интерфейсов - одна для библиотеки рабочего процесса (с составными интерфейсами), а другая для служб (вещь, объединенная в операции рабочего процесса)

Так что в моем случае имело смысл держать их отдельно.

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