Many dependencies in the Core project

[paulieadam]

Hello,

Firstly, it’s clear a lot of effort has gone into this project, and it’s appreciated by the community.

I have been looking for a good starting template for .NET projects. I am a bit hesitant to use a project with a lot of small NuGet packages in the Core. For projects that need to run smoothly for a long time and are easy to upgrade, I need to be sure that dependencies will remain supported for the long haul.

So, starting off a project by pulling out dependencies isn’t ideal for a starting template. Therefore, this project is great as a demo application, but not a good starting template.

I’m not sure if other people feel the same way, but it would be great to have a cleaner starting template with fewer dependencies.

Autofac was recently removed which is great 👍

Thanks for this great project, and keep up the good work.

[ardalis]

Hi @paulieadam,

I appreciate where you're coming from but you must balance your desire for fewer dependencies and a more generic template against the fact that this is not a generic template or a Microsoft template it is my template and as such it is somewhat opinionated. I created it to streamline the project I create for my training and for my clients and it includes many libraries that I (and others) have found to be useful. If you don't find certain ones useful, or any of them useful, then by all means remove them. Or fork the repo, remove them, and publish your own template. But the alternative for me to continue to have the functionality afforded by these packages would be to copy their contents into this template, and I don't think you would like that, either. Then instead of a few PackageReference files you'd have hundreds of classes you might not really need but would now need to maintain as part of your solution.

Hope that makes it clear why things are as they are. Please let me know if you still have questions or suggestions. Thanks!

[paulieadam]

@ardalis yes, I see where you are coming from. I use this project as a reference so thanks again for making it available 👍

[zackarhino]

Yeah, as somebody who's new to this architecture (we use Onion architecture at our company, but it doesn't really look much like this which is why I researched it), I'm totally confused as to what the benefit of this is.

To me, it makes sense as to why you would want to separate out your models from any logic (with logic being in certain services), and to build abstract interfaces so that certain parts of the app don't have to know about the implementation (alongside Dependency Injection so that you can easily swap out these implementations and invert control). At a first glance, though, I'm totally confused, and I find the code unintuitive and hard to read.

I mean, the very first principal of these architectures is that the inner layer, the domain, should only have common entities and simple business logic, but as @paulieadam mentioned, the domain models themselves already have several dependencies, which I thought that the domain layer should not depend on. The core layer also has interfaces and implementations for services, which I thought were supposed to be on higher levels so that there's not a specific implementation in the domain layer.

Can you please try to explain to me the benefit of designing an application this way? Which types of application would benefit from this design? I'm sure there are several advantages to this approach, but I can't for the life of me figure out how this is more maintainable or readable. Unless I'm grossly misunderstanding the purpose of this architecture (which is likely, to be fair), it almost seems like we have multiple layers' functions on every layer. The Use Cases have to interface with the domain models code in order to retrieve data. I mean, at least the interfaces are responsible for transferring data.

If I decided to build off of this, it would be heavily tied to your implementation, no? Seems like it would be incredibly difficult to swap out the code with mine because it's all pretty concrete, but I suppose the folder structure is the main point of this repo... please forgive me if I made any rookie mistakes. I guess I just don't 'get' it. This seems so much harder to read than a typical project but also still pretty tightly coupled. Does it help for scalable or modular applications? I will have to do more research. The Microsoft docs link here.