0

So for namespacing my repository layer, it's easy. I do something like this:

The interfaces live in Models.Repositories. So maybe I'd have Models.Repositories.IUserRepository or something.

Then I sub-namespace based on what the implementation does. So the implementation may look like so:

Models.Repositories.MySql.UserRepository

How would you do some similar logic with the service layer? Right now I just have my interfaces and implementations in a "Services" namespace, and it looks kinda.. goofy. Like, where would I put some alternate implementation?

tereško
  • 58,060
  • 25
  • 98
  • 150
Sean
  • 1,668
  • 1
  • 18
  • 28

1 Answers1

0

This really is up to you, however I like to organize based on name. First on the interfaces, I would have a folder/namespace Interfaces so they are all easily viewable/find/etc.

On the service layer - the exact same way you are doing it. 

YourCompany.Project.Services.SomeAlternateImplementation

You may choose to call your interfaces related to your service contracts as well.

YourCompany.Project.Services.Contracts
Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • So I guess what I was really wondering, is: With the repository layer, it's easy to know how to name the implementations: One connects to MySQL. Maybe another connects to MongoDB, etc... But the service layer? It selects a repository layer to use. So the service layer could be used with the MySQL repositories, or the Mongo repositories, or anything. Should it just be considered the "standard" service layer implementation? – Sean Jun 20 '12 at 11:55