1

Given a code project which is supposed to adhere to the SoC principle by implementing loosely coupled layers, having an IoC container, etc., for example, a simple ASP.NET MVC solution which is separated into the following assemblies:

  • Application assembly+namespace
  • Model assembly+namespace (contains a concrete repository to access DB data)

and where a concrete repository in the Model assembly must implement a common interface IMyBusinessRepository, in which assembly would you put that interface?

1) If you put that interface in the Model assembly, chances are that it would be impossible to replace that assembly by another one (at least if it has a different namespacing) without modifying the code of the Application assembly. Also, an alternative IMyBusinessRepository implementation residing in a different assembly would have to reference the original one (Argh!)

2) If you put it in the Application assembly, it would be impossible to use the Model assembly in other projects without referencing the Application assembly (Argh!)

3) Or would you create a separate common assembly just for that interface, and for that matter, for each common interface or set of interfaces? (Argh?)

To summarize, X assembly should be easily replaceable in application A (merely by changing a reference), and reusable in applications B, C, D.

Maxim Gueivandov
  • 2,370
  • 1
  • 20
  • 33

4 Answers4

2

You could simply use a Contracts or Interfaces assembly, as you suggested.

However, considering you are attempting to work with-in the separation of concerns principal, are you expecting to replace all the implementations of all your interfaces at the same time, or maybe just a single concrete implementation here and there.

If you expect to replace all then a separate assembly might be best, otherwise you could simply the replacement implementation in the Model assembly alongside the existing implementation and the interfaces are declared in the Model assembly as well.

benPearce
  • 37,735
  • 14
  • 62
  • 96
2

Option 3.

Putting the interface definitions in with the calling code is fine right up until you want to develop against the interfaces but not the component that's holding it (say you want to build a data access provider but you don't want to pull in the whole website project). Putting it with an implementation is just crazy talk :)

would you create a separate common assembly just for that interface, and for that matter, for each common interface or set of interfaces? (Argh?)

I would group interfaces into separate assemblies by thinking about the Commom Closure and Common Reuse principles. By being on their own they will also be more stable. Think about the scenarios in which they will be used - does keeping them together make sense - if so then they are probably OK in one assembly.

Adrian K
  • 9,880
  • 3
  • 33
  • 59
2

I would recommend to put interfaces either in separate assembly or close to their implementation within the same assembly. There should be always at least one implementation of the interface along with the interface itself. Common approach is to place interfaces in the same assembly, under separate folder.

Robert
  • 3,276
  • 1
  • 17
  • 26
-1

SoC is a logical concept which you are trying to translate into a physical one.

The only adverse effect of putting your repositories in the Model is assembly is that maybe in the future it will possible be hard to swap assemblies. I don't understand this concern? Maybe aliens will invade and we need to put galactic time in our databases. Should we code that abstraction now? Probably not.

I don't understand the concern either. Whats preventing you from having Concrete1 : IRepository and Concrete2 : IRepository in the Models assembly?

Also your probably coupling something incorrectly if the core of your application needs to be modified by a change in your Model classes. Thats a bit backwards.

John Farrell
  • 24,673
  • 10
  • 77
  • 110
  • SoC is invoked as a picture of the whole; given your assumption, if I wanted to translate SoC into a physical concept I would have to create separate assemblies for Views and Controllers which is quite meaningless in most cases. Next, in the example given in my question, a possible answer to why you would need abstraction is quite easy to imagine: switching to an implementation where a different data provider is used, which you must admit have much more chances to occur than switching to galactic time or whatever other displaced ironic example you could have. – Maxim Gueivandov Feb 20 '11 at 13:44