Handling dependencies in a one assembly
time to read 2 min | 337 words

There were several comments for my recent post about the disadvantages of creating a single assembly for a project, instead of the more common multiply ones.

The main one seems to be related to dependency management. How you can be sure that the UI isn't accessing the database, and other fun violations of layering.

I have to say that I don't really have much issue with that. I want good layering, but I find that code style in a project tend to keep consistent over a long period of time in any reasonable time. As such, once you have sufficient size, it will more or less manage itself.

That isn't going to be an acceptable answer for a lot of the people that want to have more control over that, I know. There are two answers to that, the first is from the human perspective, the second is from enforcement perspective. Let us deal with the first one first.

Make it easy to do the right thing. I seem to be saying that a lot lately, but this is a core concept that all developers needs to assimilate.

If loading a user from the database is as simple as:

usersRepository.Load(userID);

Then you can be certain that no one will try to write this:

using(SqlConnection connection = new SqlConnection("Data Source=LocalHost;Initial Catalog=MyAppDB;"))

{

    connection.Open();
    SqlCommand cmd = connection.CreateCommand();
    cmd.CmmandText = "SELECT * FROM Users WHERE Id = " +userId;

}

Yes, it is that simple. And yes, this assume non malicious people in the team. If you have those, termination is recommended. It is your choice whatever it would be of them or their employment.

Enforcement is easy as well. Get NDepends and setup the appropriate CQL queries. Something like: error if class in "MyApp.UI" references "MyApp.Infrastructure".

Tweet Share Share 19 comments
Tags: