Sunday, April 3, 2016

Contain Dependencies

This has come up several times in various applications I've worked with. You have some dependency - lets say the MVC framework for example. That dependency is a certain version, lets say 4 for sake of discussion. You have multiple csproj files in your Visual Studio solution. One of those projects is the ASP.NET MVC 4 web project, another is a bunch of models, maybe another contains a collection of helpers. One of those projects which the web proj depends on also depends on MVC, but also has some other dependencies like StructureMap or NHibernate or Automapper.


Now imagine one or more of those projects is shared amongst multiple solutions since it contains re-usable code. If any of those projects have a 3rd party dependency updated to the latest (and greatest?), what happens to the shared project? It too must be updated. Once that happens, all other solutions which use it are impacted. But what if the consuming code doesn't even use the feature that depends on the 3rd party lib? Now you're stuck holding the bag anyways...


So here's the lesson - if you're writing a lib that is intended for re-use, separate any pieces of code that have external dependencies onto their own assemblies. For example, of you have a library of helpers, have a library of core helpers then a library of helpers for each other external dependency.


Helpers.
Helpers.MVC.
Helpers.EntityFramework.
Helpers.Automapper.


Maybe even version them if you see fit.


Helpers.MVC4.
Helpers.MVC5.


By separating those dependencies this way, you can avoid potentially crippling issues down the road where suddenly your applications won't compile and you don't know why. When you finally find out, you have to wade though oodles of muck to sort it all out. Plus its just good SoC :)


Happy Coding!

No comments:

Post a Comment