Currently I'm building a large framework whose purpose is to run several algorithms in sequence.

Many of these algorithms have interdependencies in data structure - the output of one algo is the input of another algo, for instance MagicVectorXY. The algorithms need to be modular and compact, because some of these algorithms will be reused in many other separate frameworks. And we want to avoid unreachable code as much as possible.

Our current solution is to compile each algorithm into its own .dll, while shared interfaces/3rd party math libraries/shared data structures reside in a CommonInterfaces.dll. However, this leads to proliferation of Projects in the Visual Studio Solution, and there's still significant unreachable code in the CommonInterfaces.dll.

What other strategies are there to manage such a modular framework?

PS: We foresee ~10 algorithms, and things like database layer, WCF, scheduling and Unit Tests for each project are all their own projects as well. So around 25-30 projects estimated in that single solution.

  • 1
    25-30 C# projects in a single solution is not many, VS will handle that well. But what I do not understand is why you have any "unreachable code" - if code is unreachable, it is superfluous and can be deleted.
    – Doc Brown
    Jun 12, 2015 at 6:42
  • All of the shared data structures are packaged under the CommonInterfaces.dll, however each algorithm only uses a small subset of it. So if a particular algorithm isn't used, including the .dll would pull in lots of code that is never executed as well.
    – Cardin
    Jun 12, 2015 at 8:02
  • 1
    But on 2nd thought... that is true for most 3rd party libs. There's a lot of unused code inside.. (e.g. Boost)
    – Cardin
    Jun 12, 2015 at 8:03
  • 2
    So you did not mean "unreachable", you meant the code is just not used by each algorithm? That is a completly different thing and perfectly acceptable, especially when it saves you duplicate code.
    – Doc Brown
    Jun 12, 2015 at 8:58
  • If the models are in shared interface though I would have thought a single datalayer project would be enough
    – Ewan
    Jun 12, 2015 at 9:14

1 Answer 1


The information here is a bit scarce...

First of all (if you haven't already) you may want to check out SOLID. Follwing these rules will give your sofware a good dependency structure. A nice dependency structure is key to being able to swap modules in and out. (And you will not need to reference the datalayer to compile your algorithms)

What strikes me the most in your description is "shared interfaces". To make each algorithm a true module you want each module to individually define the interfaces it uses. See ISP. Then the implementation of the different interfaces can be in a single class that references the algorithm .dll:s but you can also provide different implementations for different frameworks if needed. Or maybe you have a default implementation that you can package with the module.

Also, don't be afraid to add projects. And I would recommend thinking about structuring the code by functionality (module/algorithm/etc.) instead of just different layers as that will allow you to for example pick the parts of the data layer you need.

  • The SOLID principles were very helpful! In the end I settled for a generic IAlgorithm interface with Run() and a generic IAlgoParam input. The middle layer is agnostic to it all, while the front-layer and back-layer knows which objects to supply or cast to.
    – Cardin
    Jul 13, 2015 at 5:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.