4 ms·

Would most people here agree that .NET is a much better platform for developing applications with a plugin-based architecture (which, I think, more or less, imp

by ablekh 6y ago

Would most people here agree that .NET is a much better platform for developing applications with a plugin-based architecture (which, I think, more or less, implies following Hexagonal aka Clean Architecture / Ports and Adapters Pattern [1]) than popular alternatives (e.g., Python, TypeScript/Node.js) due to a diverse set of comprehensive dependency injection (DI) implementations [2]? While it is possible to use a manual / non-DI approach [3], the trend seems to be in either extending this approach [4-5], or - an arguably more elegant and flexible solution - using DI [6]. Would love to hear opinions on how you would approach developing a heavily plugin-based application (including an ability to use virtualization containers, such as Docker, as functional plugins). [1] https://www.infoq.com/articles/advanced-architecture-aspnet-core https://www.infoq.com/articles/advanced-architecture-aspnet-... [2] https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-list-of-net-dependency-injection-frameworks https://www.claudiobernasconi.ch/2019/01/24/the-ultimate-lis... [3] https://docs.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/en-us/dotnet/core/tutorials/creat... [4] https://github.com/natemcmaster/DotNetCorePlugins https://github.com/natemcmaster/DotNetCorePlugins [5] https://maartenmerken.medium.com/announcing-prise-a-plugin-framework-for-net-core-4af7cf5b4d2b https://maartenmerken.medium.com/announcing-prise-a-plugin-f... [6] http://ewer.com.br/plugin-architecture-with-di-containers http://ewer.com.br/plugin-architecture-with-di-containers

bob1029 6y ago
The DI in .NET is really powerful and feels intuitive once you play around with it in a few different projects. We have almost 100 services injected into .NET Core DI and it always feels very stable and manageable. For us, we cheated a little bit on many services and just take a dependency on IServiceProvider to get at other services at runtime. This allows for any service to talk to any other service without worrying about some monster CTOR hierarchy. We used to try to keep things "correct" in terms of dependency chain, but we have found that the real world is a lot easier to work with when you permit circular dependencies between services and maintain 1 big flat collection of them. This is basically microservices but without the RPC ceremony and associated nightmares.
- ablekh 6y ago
  Thank you very much for sharing your DI experience. What is wrong with using IServiceProvider dependency? What is CTOR (hierarchy)?
  - kumarvvr 6y ago
    CTOR heirarchy - Constructor Hierarchy. You have to have your constructors such that the ones needing a lot of services and in-turn those services needing a lot of other services need to be added to the service container and ensured to be instantiable. Essentially, you build a tree of your services and have to ensure that all your constructors have objects that can be instantiated or managed by the DI system.
    - ablekh 6y ago
      Understood. Thank you for clarifying.
  - bob1029 6y ago
    CTOR hierarchy in this case refers to a rigid structure in which you are not allowed to have any circular dependencies. E.g.: If UserService and AccountService eventually evolve into needing to talk to each other, you can wind up in this situation. Most would argue you should refactor both services, create a 3rd service or slam the 2 together into 1. I argue that both have independent persistence layers and it makes a lot of sense from a business perspective to have these modeled separately. So, the implication is that IServiceProvider is a way to "cheat" the system by not requiring you perform an impossible circular CTOR setup where UserService requires AccountService and vice versa. DI cannot resolve dependencies which require each other. In terms of actual harms, I do not really think there are any substantial ones to note. This is technically reflection but only slightly and I haven't been able to notice any performance impact, but we don't do IServiceProvider lookups in tight loops either.
    - ablekh 6y ago
      Got it. I appreciate your detailed and clear reply.
oaiey 6y ago
I think Python, TS/JS and other popular languages do not block onion architectures / hexagonal architecture. Or most other patterns. It is a matter of will and the right execution. Also, DI is not the same DI containers. If I have three components and inject two into another one, I do DI but for sure will not instantiating a DI container for it ;)
- ablekh 6y ago
  I didn't mean that non-.NET stacks are somehow antagonistic to hexagonal architecture. It's just that, based on what I have been reading on the subject, I came to a conclusion that .NET has the most comprehensive support of said architecture thanks to a diverse and feature-rich ecosystem of relevant frameworks (including DI ones), whereas alternative stacks are significantly behind in this regard.

by ablekh 6y ago

bob1029 6y ago

The DI in .NET is really powerful and feels intuitive once you play around with it in a few different projects. We have almost 100 services injected into .NET Core DI and it always feels very stable and manageable. For us, we cheated a little bit on many services and just take a dependency on IServiceProvider to get at other services at runtime. This allows for any service to talk to any other service without worrying about some monster CTOR hierarchy. We used to try to keep things "correct" in terms of dependency chain, but we have found that the real world is a lot easier to work with when you permit circular dependencies between services and maintain 1 big flat collection of them. This is basically microservices but without the RPC ceremony and associated nightmares.

ablekh 6y ago
Thank you very much for sharing your DI experience. What is wrong with using IServiceProvider dependency? What is CTOR (hierarchy)?
- kumarvvr 6y ago
  CTOR heirarchy - Constructor Hierarchy. You have to have your constructors such that the ones needing a lot of services and in-turn those services needing a lot of other services need to be added to the service container and ensured to be instantiable. Essentially, you build a tree of your services and have to ensure that all your constructors have objects that can be instantiated or managed by the DI system.
  - ablekh 6y ago
    Understood. Thank you for clarifying.
- bob1029 6y ago
  CTOR hierarchy in this case refers to a rigid structure in which you are not allowed to have any circular dependencies. E.g.: If UserService and AccountService eventually evolve into needing to talk to each other, you can wind up in this situation. Most would argue you should refactor both services, create a 3rd service or slam the 2 together into 1. I argue that both have independent persistence layers and it makes a lot of sense from a business perspective to have these modeled separately. So, the implication is that IServiceProvider is a way to "cheat" the system by not requiring you perform an impossible circular CTOR setup where UserService requires AccountService and vice versa. DI cannot resolve dependencies which require each other. In terms of actual harms, I do not really think there are any substantial ones to note. This is technically reflection but only slightly and I haven't been able to notice any performance impact, but we don't do IServiceProvider lookups in tight loops either.
  - ablekh 6y ago
    Got it. I appreciate your detailed and clear reply.

oaiey 6y ago

I think Python, TS/JS and other popular languages do not block onion architectures / hexagonal architecture. Or most other patterns. It is a matter of will and the right execution. Also, DI is not the same DI containers. If I have three components and inject two into another one, I do DI but for sure will not instantiating a DI container for it ;)

ablekh 6y ago
I didn't mean that non-.NET stacks are somehow antagonistic to hexagonal architecture. It's just that, based on what I have been reading on the subject, I came to a conclusion that .NET has the most comprehensive support of said architecture thanks to a diverse and feature-rich ecosystem of relevant frameworks (including DI ones), whereas alternative stacks are significantly behind in this regard.