views:

32

answers:

1

So I'm developing a very cool (and very large) n-tier application.

Basically I have the following assemblies:

Domain
Domain.Contracts

Services
Services.Contracts

Presentation.Admin
Presentation.Web
Presentation.Core (shared between Admin & Web)
I may implement Presentation.Core.Contracts

My main issue I'm wrestling with are name collisions between the different layers. Ie.

Services.Contracts.AccountServicesRequest
Domain.Contracts.AccountServicesRequest

I had the same issue with Service names (in this case I am just using classes as services rather than WCF, etc). Ie:

Services.Contracts.IAccountService
Domain.Contracts.IAccountService

I resolved this by now making all "service handlers" in the domain layer IxxxServiceHandler which gives me this:

Services.Contracts.IAccountService
Domain.Contracts.IAccountServiceHandler

However, I haven't been able to resolve this issue with the objects that are passed back and forth between layers. This seems to be sprinkled in a bunch of places through my solution(s). I was just curious to see if anyone has had the same issues. If so, how did you resolve them?

A: 

Yes, I have run into this problem, but I have fixed it soon enough every time.

A good class naming convention can help. Avoid using the same name in classes across multiple layers.

Alternatively, you can use namespace aliases, so that you would be using, for example:

services::IAccountService
domain::IAccountService

Does this help?

CesarGon
Haha! Yes this does help but maybe you could give me an example.Let's say (for simplicity) I have 3 layers:(1) Domain\Domain.Contracts(2) Services\Services.Contracts(3) PresentationIf I have a User object in Domain and IUser and/or UserDto what would you name these objects in the other layers?
devlife
Well, I would need to know exactly *what* you are naming in order to determine the optimal name for it. :-) Things such as "Contract", "User", etc. sound very much like problem-domain concepts, which I would suggest to place in a single business-logic layer. You don't want to replicate these classes elsewhere. You could have classes such as Business.Contract and Business.User. (TBC)
CesarGon
On the presentation layer, you could have, for example, Presentation.ContractDialog or Presentation.UserWindow. A "contract dialog" is a dialog box that displays a contract; you wouldn't have Presentation.Contract because contracts themselves are modelled *only* in the business logic layer. Does this make sense?
CesarGon
Thanks CesarGon. This does make sense. After some studying / playing around I figured out how I'll do this. My real issue was that I was passing dtos between the domain and services layers. Instead I'm passing interfaces between domain and services layers and having the domain implementation internal. Then I have a dto in the services layer which also implements the domain interface. Thanks for your help.
devlife
You're most welcome. :-)
CesarGon