Problem with ASP.NET MVC 3 solution layout

.NET
1

Hello,

Umm. I though that i would put the contexts, mappings in the ProjectName.Data project and repositories, entities, services, etc. in the ProjectName.Domain project.

However im getting a referencing problem. In Data i need to access the domain namespace and in the domain namespace i need to access the data namespace and when i add reference (Data project get reference to domain and i wanted to have domain get a reference on data) it say that it cannot because that would create a circular dependency.

Any helps ? Where each stuff normally belong to ?

Edit: I though of a better solution. Would this do ?

Domain -> Entities and domain logic
Core -> Repositories, Context and everything related to core of the application.
Services -> Services and components (sub-services)
UI -> MVC 3

I know this is up to anyone but i just need some opinions.

Thanks!

2

Try this layout for starters. You’ll develop one of your own later I’m sure, but this is the simplest.

Project.Domain

  • Entities (domain logic built in)
  • Repository Interfaces

^ must exist before continuing

Project.Persistence

  • Context
  • ClassMaps
  • Repository Implementations

^ must exist before continuing

Project.Web

  • The MVC Project

If needed, you can additional have:

Project.Services

  • Services (such as EmailService, LoggingService, PricingService)
3

Well that what ive come with except “persistence” i am calling it “data”. Is there a reason why Repository Interfaces are implented to the domain ? As for UnitTests is there a Project.[each].TestUnits or you recommand one project for all unittests ?

Thanks.

4

Repository Interfaces are declared in the Domain not implemented. Implementation is in your “data” project.

I usually have a dedicated project for all tests in the solution

5

“Repository Interfaces are declared in the Domain not implemented. Implementation is in your “data” project.”

Yeah i know.

Are services interfaces also part of the domain ?

And i am not fully understand this : “dedicated project for all tests” did you mean one per project or one for all projects ?

Sorry english isnt my primary language so there some meaning unsure to me.

Thanks. :slight_smile:

6

Typically service interfaces are not defined in the domain layer because one strives to put all their domain logic in the entities.

Some services end up being stand-alone and re-usable, such as an EmailService or LoggingService. Such services are portable between other applications.

The line is foggy though when a service acts upon domain entities. That ties it to the domain, and in such a case, I wouldn’t raise a brow at seeing those particular interfaces in your domain library. The implementations should remain outside of it though.

In regards to tests, it is entirely up to you. While Praetor likes the single test project per solution, I prefer the one-to-one ratio. If somebody needed just the domain and persistence layer, I’d give them those two libraries and their respective tests.

7

Alright, thanks guys ! :slight_smile: Yeah, i think this can be a good idea to put domain related services interfaces at the domain level and implement them at the service level. Application services and others kinds of services might be available only at the service level.

As for tests i might end up having one test project per project.