„Przyjazna” biblioteka Dependency Inject (DI)

Zastanawiam się nad projektem biblioteki C #, która będzie miała kilka różnych funkcji wysokiego poziomu. Oczywiście te funkcje wysokiego poziomu będą implementowane przy użyciuSOLIDNY zasady projektowania klas w jak największym stopniu. W związku z tym zapewne będą klasy przeznaczone dla konsumentów do regularnego korzystania z nich i „klasy wsparcia”, które są zależne od bardziej powszechnych klas „użytkowników końcowych”.

Pytanie brzmi, jaki jest najlepszy sposób zaprojektowania biblioteki, a więc:

DI Agnostic - Chociaż dodanie podstawowego „wsparcia” dla jednej lub dwóch wspólnych bibliotek DI (StructureMap, Ninject, itp.) Wydaje się rozsądne, chcę, aby konsumenci mogli korzystać z biblioteki z dowolnym środowiskiem DI.Nie-DI użyteczne - jeśli konsument biblioteki nie używa DI, biblioteka powinna być nadal tak łatwa w obsłudze, jak to możliwe, zmniejszając ilość pracy, jaką użytkownik musi wykonać, aby utworzyć wszystkie te „nieistotne” zależności, aby dostać się do „prawdziwe” klasy, z których chcą korzystać.

Moje obecne myślenie polega na udostępnieniu kilku „modułów rejestracji DI” dla wspólnych bibliotek DI (np. Rejestru StructureMap, modułu Ninject) oraz zestawu lub klas Fabryki, które nie są DI i zawierają sprzężenie z tymi kilkoma fabrykami.

Myśli?

questionAnswers(4)

yourAnswerToTheQuestion