Are you a dependency slob?
Tracking in user interface sludge all throughout the polished wood floor of your business logic layer?
I’ve done it.
We rush to meet deadlines, slinging code wild west style, no shame at all in hardcoding object instantiation with the
new keyword, slipping some logging code into our formerly SOLID methods, or forcing dependencies on the clients of our classes by requiring class implementations as parameters.
As long as it works, right?
This article marks the next step in our look at the book Adaptive Code via C# (see part 1 here). The goal of Chapter 2: Dependencies and Layering is to show us why we should take more care and consideration when we connect the pieces of our applications together and some ways in which we can begin.
Instead of summarizing each chapter section, piece by piece, I’ve taken 3 useful nuggets of wisdom from the author and put them into a list.
Keep in mind, like most advice in software development, there is rarely a time where you should do something no matter what and in every case. Take each suggestion, roll it around in your mind a bit, and think about when it would make sense and when it wouldn’t.
Don’t cross layer boundaries
The concept of a dependency moves along a spectrum from macro to micro. A web server can depend on a database server, a WinForms app depends on the Windows OS, the components of the app can be made up of a user interface which depends on a business logic layer and a data access layer. This of course continues down to assembly, class, method, and variable dependency chains.
The universe is like, a huge web of dependencies, man…
Now, this tip might seem obvious, but it’s critical and needs to be said. If you (or developers before you) have designed a system made up of different layers, it’s up to you to be diligent about keeping them separate so that you retain the benefit.
What is the benefit, you say?
Let’s use an example.
Let’s say you have an application that has three layers, a UI layer, a business logic layer, and a data access layer, and your UI layer is made up of ASP.NET Razor pages or WebForms controls.
You write an email address format validation method in your business logic layer, and without thinking, you pass the entire WebForms
TextBox control to the method and let the method handle grabbing the actual text. It was convenient for you at the time, but now you’ve linked implementation details (the WebForms platform) to your business logic layer, making it unusable to platforms that don’t support WebForms.
Of course, the better move would be to pass the email address as a plain old
string. By keeping parameter types as basic as possible, you decrease dependencies and increase portability.
Avoid “spaghetti potentials” by putting compassion into your public parameter types
This follows along with the previous tip, take some time when creating public methods to consider their future clients.
In the book, the author uses the example of an API method for changing a user’s password. In the example, an
AccountsController API controller depends on a
SecurityService class for changing the password. The
SecurityService has a
ChangePassword method that takes an entire
User object as a parameter.
Although that may make logical sense, the issue is that now every client that wants to use that method must know how to create
User objects. Notice how the controller method above had to first get ahold of a repository and get the full user object just to call the
Worse yet, the
User class and the repository likely have their own set of dependencies, so you’ve created what I am calling a spaghetti potential. There is now potential for future developers to thread dependency chains throughout various assemblies if they find themselves rushing to implement a password change feature.
The better move here would be to let the
SecurityService create the
User object itself, and only require clients to pass the integer ID of the user.
Purify your methods by using Aspects
The term cross-cutting concern is when you’ve got a method that is laced with tasks that may be related but are ultimately separate. The best example of this is logging code.
You’ve got a method that updates a user’s email address, but you’ve also thrown in some audit code to record that the change was made so you can go back and see who did it and when.
The author shows a great example of turning the logging code (as well as the code involved in wrapping a database call in a transaction) into separate aspects with method attribute decorators.
Another example you may be more familiar with is
ActionFilter attributes in .NET Web API. Separating your model validation into it’s own filter like shown in my API birds-eye view guide keeps code clean and clear.
Now that you’ve seen a few ways we can be more discerning and thoughtful as we code, I know that next time you’re behind the keyboard, you’ll slow down and be deliberate about the dependencies you create.
You’ll respect layer boundaries as best you can, so not to pollute differing components. Keeping assemblies and layers loosely coupled gives us the best chance at easy future changes, testability, and reusability.
You’ll consider all current and future clients of your public methods. What parameter types would create the fewest dependencies? Will you be forcing clients to know too much?
And finally, you’ll watch out for cross-cutting concerns, looking for ways to keep your methods as single-focused as possible so that they can be understood (and tested) easily by others.