Question

I’m creating an n-tier application with Visual Studio 2010.

I have a project with only app configs, a project with only tests, and a project with only contracts (interfaces).

In a logical model, where should you enter application config values, tests and contracts?

Is this good practice?

Answer 1

You want separate test projects for each project you are testing. Assuming they are truly unit tests, then e.g. VENUS.Repository.Tests will only reference VENUS.Repository directly. In practice this will probably not quite pan out unless you mock everything, but still, separating the projects will give you much more clarity of purpose.

---

I think a separate project for “contracts” (interfaces I assume) is misguided. Interfaces are the public entry point that one layer uses to reference other layers. As such, they belong in their respective layers. That is, IFooRepository belongs in VENUS.Repository, not in VENUS.Contracts. (But, see discussion in the comments.) If you put them all in one assembly, you are destroying the n-tier separation by saying “anyone who wants to interface with any layer, just reference VENUS.Contracts and you can run wild.”

---

Finally, and this is a bit more situational, but my instinct would be to have a single config file in your composition root (usually the UI layer), and inject the configuration dependencies into the components as you compose them. So e.g. a connection string doesn’t go in VENUS.Config which gets referenced by VENUS.Repository (as well as everyone else), but instead goes in VENUS.UI.Web‘s app.config. Then, when VENUS.UI.Web composes its repository dependency, it passes that configuration in to the repository constructor. For example:

string fooConnectionString = ConfigurationManager.ConnectionStrings["Foo"].ConnectionString;
IFooRepository fooRepo = new SqlFooRepository(fooConnectionString);
// Now, as you compose the rest of your dependencies,
// inject fooRepo into anything that requires an IFooRepository.

(This is of course an example of “poor man’s dependency injection”; if you plan on using a proper dependency injection framework there will be nicer ways of doing the composition.)

This way your repository layer has no conceptual dependency on the concept of “configuration,” but instead just expresses what it needs in the natural way of object-oriented programming: constructor parameters.