解决方案中的多个项目：接口命名约定

Question

I was wondering what the naming convention for an Interface sub project within a solution would be. I know interface files start with an "I", does this apply to projects as well?

I have separated the interface into a separate project to keep the solution organised, as opposed to creating a interface file within the project which would be implementing the interface.

All files and projects are contained within one solution.

I apologise if this doesn't read well.

Answer 1

This is a common pattern for organizing solutions with many projects. However, there is some debate whether (in some cases) it is worth it.

I've seen a few different naming conventions used:

1. Inc.Project.Contract
2. Inc.Project.Contracts
3. Inc.Project.Interface
4. Inc.Project (like a base project that is a common dependency)
5. Inc.Project.Common

Answer 2

This is the way MS uses it <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

For example, Microsoft.WindowsMobile.DirectX. see link http://msdn.microsoft.com/en-us/library/ms229026.aspx

Answer 3

I agree with the naming convention that dtryon wrote in its answer.

But do not over-engineer the design of your solution. If you don't need to reference your interface from multiple projects, I don't think separating your interface in its own project is useful. It adds complexity but very few benefits.

Same thing for the interface file itself: if you do not plan to reference an object instance using the interface type (and not the type of the object that actually implements the interface), the interface isn't really useful.

Answer 4

I usually follow a pattern of ...

1. MyAppSolution - empty solution
2. MyApp.App - client facing application
3. MyApp.Adapters - project containing interfaces
4. MyApp.DAL - the data access layer

That's usually as simple as I make it ... If things are more complex, I may have a services project or a business rules project or something of that nature ... the reason I use an interface project is that I want the client application to be completely ignorant of the back end implementation; that way if I need to change an implementation, the client is not affected (does not have to change) as long as I don't change the interfaces ... And, this really happens ... I have changed DBMS's before, I have changed from a DBMS to an API, etc ... When initially building out an app, the extra layer of abstraction can seem like overkill until you need it, then it is a god send ...