Clean Architecture with ASP.NET Core 2.1 | Jason Taylor

SSW TV | Videos for developers, by developers · 311K views · 2018 · 49:20

Open on YouTube

Software architecture & designWeb developmenttalkdated

Why Stack Overflow recommends it

Stack Overflow users link it when recommending Clean Architecture for .NET apps, and some follow its code, such as the EF Core ApplyAllConfigurations extension, in their own projects.

Recommended by 3 people across 3 different months, 2019 to 2020.

What it is

A conference talk by Jason Taylor at DDD Sydney 2018 on structuring ASP.NET Core 2.1 applications with Clean Architecture. It walks through the domain, application, persistence, infrastructure and presentation layers using a Northwind Traders sample project, with source code on GitHub.

What people said

Strong rec JD Davis · 2020-09 · Stack Overflow · on “Should POCO classes contain methods? If yes, how are they difference from domain objects?”

By definition, POCOs do not have any logic within them. They're mainly a holder class, consisting only of various fields and properties. Once you start adding logic into them, you start heading further down the road of domain driven design. Many developers, like Martin Fowler rightfully argue that widespread use of POCOs lead to an Anemic Domain Model [LINK] , which Wikipedia [LINK] defines as: "...the use of a software domain model where the domain objects contain little or no business logic". In my opinion, an anemic model while using EF is definitely a real risk if you do not take proactive measures to mitigate it. That's not to say every system employing POCOs for entities is inherently

Recommends Antonio · 2019-03 · Stack Overflow · on “Rest Architecture: Data Access Layer as Model, REST purpose is to call Business Logic Layer that calls DAL”

Regarding your code snippet, I see your BLL (which I consider your app domain) depending from the DAL. If you change the DAL structure in the future, you'll also be forced to change the BLL too (which is not the best). So, a quick win could be to decouple them a bit by adding Dto's or common interfaces. Skipping "the models" can easily become so hard to maintain in the future. I'd also like to give you a more generic suggestion. If you really want to push your knowledge forward and you have plenty of time and resources to dedicate on refactoring, I'd like to suggest you to have a look at Clean Architecture philosophy. My personal starting point was this video Clean Architecture with ASP.NET

Recommends Ak777 · 2020-01 · Stack Overflow · on “How should I instantiate multiple instances of a single class with .net core DI?”

IMHO, and with my experience, i would lean towards factory pattern (based on what i have understood and your above problem stmt/example only). And that way, the controller doesnt know the actual implementation of the ReceipeFactory. In future if the receipe factory adds more different implementation or extensions, your controller wont be requiring a change. At all times, it would get the REceipeStep from the factory and send it to oven to bake. you may want to learn and explore about Clean code architecture and that may be elaborate but would be wider to understand the different patterns and features for every problem statement. One such that i'd love is available on [this video] . and another (i

Cites Ajay Verma · 2019-01 · Stack Overflow · on “ModelBuilder' does not contain a definition for 'ApplyAllConfigurations'?”

I am following this youtube [this video] video and at time 34:05 [this video] , It is architecure for ASP.Net core using EntityFramework Core and they are showing an extension method modelBuilder.ApplyAllConfigurations(); I tried this in my code and it throws error: 'ModelBuilder' does not contain a definition for 'ApplyAllConfigurations' and no accessible extension method 'ApplyAllConfigurations' accepting a first argument of type 'ModelBuilder' could be found (are you missing a using directive or an assembly reference? Am I missing any reference? If not, How can I implement this in my Project?