0

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?

CesarGon
  • 15,099
  • 6
  • 57
  • 85
devlife
  • 15,275
  • 27
  • 77
  • 131

1 Answers1

0

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
  • 15,099
  • 6
  • 57
  • 85
  • 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) Presentation If I have a User object in Domain and IUser and/or UserDto what would you name these objects in the other layers? – devlife Dec 10 '09 at 21:49
  • 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 Dec 10 '09 at 22:50
  • 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 Dec 10 '09 at 22:51
  • 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 Dec 11 '09 at 12:49