StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PODo internal sealed classes run perpendicular to proper DI?
text
Body
copied!<p>After reading Mark Seemann's book on Dependency Injection, I'm stoked about moving my team away from the service locator anti-pattern and into a more elegant solution where my DI is not ever present in our code. Though we had an interface that decoupled us from our DI container of choice, I always felt like we were too dependent on the container and - at the same time - were unable to take full advantage of it and I see a lot of good reasons to move towards constructor injection + abstract factory patterns.</p> <p>My problem has to do with policy and procedures: We try to follow SOLID and related principles to the T. We also mark our classes as internal sealed unless they have an (obvious) reason NOT to be. This has always been nice in the past as it prevents us from violating our "code to an interface" philosophy since all that is visible across assembly boundaries are interfaces, only available via our container.</p> <p>While practicing Mark Seemann's advice, it occurs to me that my classes need to be public so that the composition root is able to compose the desired components together. This seems especially true when building a shared library that should not assume its referencing code will use a container, especially its flavor of a container. </p> <p>I have also reached this conclusion when building mappers that map from one assembly's objects to another. For example, I might have a Models.Interfaces layer that is used by Business and Repository layers to pass data back and forth. Before, we would simply make an assembly that implemented the contracts in Models.Interfaces, and both Business and Repository would use a service locator whenever they needed a new instance of a Model.Interface. Without a service locator, it seems my only choice is to either drop Model Interfaces, or have implementations of my Model.Interfaces in the very same project, allowing Business/Repository to new up instances as needed.</p> <p>Performance aside, I want to know if having public Model implementations in the Model.Interfaces project is a design smell, and I want to know if internal sealed classes can live in harmony with this approach to DI, and whether or not I'm missing something when it comes to coding to an interface AND using constructor injection + abstract factory DI patterns.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload