MonochromatiqueВопрос такой - до какой степени принято (если тут это уместно), делать приложение "слабосвязанным"? Где та грань, показатель "достаточно"?

Ведь в стремлении к декомпозиции можно дойти до "один метод - один класс". А потом уже собирать всё каким-нибудь NINJECT-ом.

эта определённая грань существует. это границы вашего контроля над кодом.

сама природа DI подразумевает инверсию абстракции. в отличие от классического подхода, где нижние слои ничего не знают о верхнем слое, здесь верхние слои ничего не знает о нижних слоях. в этом и проявляется слабая связность компонентов.

поясню. нижний слой реализует некий интерфейс, который использует верхний слой. в таком случае, необходимо знать, что это за интерфейс. возможно это будет дополнительная сборка — хранилище интерфейсов.

в итоге, слабая связность выливается в дополнительный кодинг. ещё одним минусом является, что при очень слабой связности может быть достаточно трудно разобраться, что же от чего в итоге зависит, и как это всё работает.

резюмирую ответ на вопрос. до такой степени, чтобы это было уместно :) как уже сказали выше, по логическим слоям приложения. в принятии решения должно участвовать здравое разумение о тестировании и взаимозаменяемости компонентов. там, где это не нужно, DI не нужен.

1. тестируемость. если функциональность компонента детерминирована (отсутствуют какие-либо побочные эффекты, оказываемые на работу приложения) — DI не нужен.
2. взаимозаменяемость. если имеются предположения о возможной замене реализации конкретного слоя, или подмене реализации при изменении условий — DI нужен.

Monochromatique,

про слои легко гуглится, литературы достаточно. бест практики бест практикам рознь. без конкретной задачи и конкретных условий, ваш вопрос вообще лишён какого-либо смысла.

вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов? люди говорят, насколько дури хватит, может что-то ещё??

MonochromatiqueИ про асинхронность никто не ответил.

я так и не понял при чём тут асинхронность и DI.

если будете использовать механизм конечных автоматов (async/await) введённых в .NET 4.5, задача упрощается. посмотрите, например, на реализацию Entity Framework 6, большая часть функций имеет асинхронные аналоги (в том числе и для PLINQ). если вы делаете универсальную библиотеку для широкого пользования, то уместно будет поступить также. а для своего приложения, делайте асинк там, где он требуется или может потребоваться. и не делайте, если не нужен и не потребуется. в чём проблема?