2009-12-09 3 views
0

Итак, я разрабатываю очень крутое (и очень большое) приложение n-уровня.Название столкновения между слоями

В основном я следующие узлы:

Доменные
Domain.Contracts

Услуги
Services.Contracts

Presentation.Admin
Presentation.Web
Presentation.Core (общий между Администратором & Веб)
Я могу реализовать Presentation.Core.Contracts

Моя основная проблема, с которой я борюсь, - это столкновения имен между разными слоями. Т.е.

Services.Contracts.AccountServicesRequest
Domain.Contracts.AccountServicesRequest

Я была такая же проблема с названиями услуг (в данном случае я просто с использованием классов в качестве услуг, а не WCF, и т.д.). То есть:

Services.Contracts.IAccountService
Domain.Contracts.IAccountService

Я решил это сейчас делает все "обработчики служб" в IxxxServiceHandler домена слоя, который дает мне это:

Services.Contracts .IAccountService
Domain.Contracts.IAccountServiceHandler

Однако, я не был в состоянии решить эту проблему с объектами, которые передаются назад и вперед между слоями. Это, кажется, посыпается в кучу мест через мое решение (ы). Мне было просто интересно узнать, есть ли у кого-то такие же проблемы. Если да, то как вы их разрешили?

ответ

0

Да, я столкнулся с этой проблемой, но я исправил ее достаточно быстро каждый раз.

Хорошее соглашение об именовании классов может помочь. Избегайте использования одного и того же имени в классах на нескольких уровнях.

В качестве альтернативы, вы можете использовать namespace aliases, так что вы будете использовать, например:

services::IAccountService 
domain::IAccountService 

ли эта помощь?

+0

Ха-ха! Да, это помогает, но, может быть, вы могли бы привести мне пример. Допустим (для простоты), у меня есть 3 слоя: (1) Домен \ Domain.Contracts (2) Услуги \ Services.Contracts (3) Представление Если у меня есть объект пользователя в домене и IUser и/или UserDto, что бы вы назвали эти объекты в других слоях? – devlife

+0

Ну, мне нужно точно знать, что * вы называете, чтобы определить оптимальное имя для него. :-) Такие вещи, как «Контракт», «Пользователь» и т. Д., Очень напоминают концепции проблемной области, которые я бы предложил разместить в одном бизнес-логическом уровне.Вы не хотите копировать эти классы в другом месте. У вас могут быть такие классы, как Business.Contract и Business.User. (TBC) – CesarGon

+0

На уровне презентации вы можете иметь, например, Presentation.ContractDialog или Presentation.UserWindow. «Диалоговое окно контракта» представляет собой диалоговое окно, в котором отображается контракт; у вас не было бы Presentation.Contract, потому что сами контракты моделируются * только * на уровне бизнес-логики. Имеет ли это смысл? – CesarGon

Смежные вопросы