In a multi-tier architecture, is it OK to have adjacent layers reference one another?

If I have an app that consists of multiple layers, defined as multiple projects in a solution, is it ok to have a layer reference the layer directly above/below it? Or, should one use dependency injection to eliminate this need?

I am building on a more specific questions that I asked here, but I would like more general advice.

How would I go about setting up a project like this in VS2010? Would I need a third project to house the DI stuff?(I am using Ninject)

EDIT: example

Here is an example of my two layers. first layer has an IUnitOfWork Interface and the second layer has a class that implements said interface. Setup in this manner, the project will not build unless layer 2 has a references to layer 1. How can I avoid this? Or, should I not even be wo开发者_StackOverflow中文版rried about references and leave it alone since the layers are adjacent to one another?

Layer 1

public interface IUnitOfWork
{
    void Save();

}

Layer 2

 public DataContext : IUnitOfWork
 {
     public void Save()
     {
          SaveChanged(); //...
     }
 }

---

General advise is to decouple layers by interfaces and use Dependency Injection and IoC containers for great level of flexibility whilst maintaining an Application. But sometimes it could be an overkill for small applications, so to give you a more specific example you have to provide at least description of the application and layers which it has.

Regarding DI stuff, I would suggest to encapsulate it in a separate assembly.

See great article by Martin Fowler Inversion of Control Containers and the Dependency Injection pattern

EDIT: Answer to comments regarding interface

Only one way to get rid of such coupling is to store common interfaces/classes in a separate assembly. In your case create separate assembly and put here is IUnitOfWork interface.

EDIT: Ninject projects reference

There are 147 Ninject projects, I would suggest to download and investigate most interesting from your point of view: Ninject projects

---

This is a known "Tightly Coupled vs Loosely Coupled" dilemma and there is no general recommendation for it. It depends very much on how large are your component, how do they interact, how often are they changing, which teams do work on them, what are your build times.

My general advice would be keep balance. Do not go crazy by decoupling every mini class and on the other hand do not create a monolith where one small modification causes rebuild of the whole world.

• Where change is expected, Favor loosely coupled components
• Where stability is expected, Favor tightly coupled components

It is always a trade off:

There are costs associated with each decision:

The cost of having to make changes across tightly coupled components are well known. -The change is invasive -It may take a lot of work to determine everything in the dependency chain -It's easy to miss dependencies -It's difficult to insure quality

On the other hand, the costs of over-engineering are bad too -code bloat -complexity -slower development -difficult for new developers to become productive

To your example: Take a look at Stoplight Example coming along with Microsoft Unity Application Blocks

---

People have already answered your question. I would suggest that the "below" layer should not reference the "above" layer as the below layer purpose is to provide certain functionality which is consumed by above layer and hence it should not know anything about above layer. Just like the nice layer model of TCP/IP stack