An Overview of eShopOnWeb, an ASP.NET Core Reference Application

In this overview, Steve shows how to download, build, and run the eShopOnWeb sample from Microsoft. This is a reference application designed to show how to build ASP.NET Core web applications and Blazor WebAssembly Single Page Apps (SPAs).
You can download the sample from: github.com/dotnet-architectur... -- Watch live at / ardalis

[@sckoobs]

Fantastic and really valuable coverage of eShopOnWeb Steve. Thanks for doing this and for publishing to KZbin. The questions really helped to get the most out of the explanation, some really good insights for those who watch all the way through.

[@IvanRandomDude]

Great video! I especially like that endpoint pattern in API project. Never seen it before

[@vidzhel]

Soo useful, it's like I've just read Clean Architecture, but with great examples of implementation

[@lucassmith6320]

This really helps! This is actually my first time try to read source code and this video helps a lot! Thanks!

[@slutmonke]

Thanks so much for including the twitch chat in these for context. It's crazy how many content creators port their streams to youtube without doing that.

[@Ardalis]

You’re welcome!

[@nhwilly1011]

Thank you. Great discussion and I watched all the way to the end.

[@Chana999]

Thank you !! your video help me a lot to understand concepts that are in the eShop solution. Also, you explains very well the code and concepts ... really !! Thank you !!

[@Ardalis]

Glad it was helpful!

[@iT_dev41k]

very very very cool and useful info in 1 video! thanks a lot!

[@thesuperiorman8342]

Glad I stumbled on your channel

[@hpdev93]

Thanks for making this video and clearing up lots of concepts.

[@Ardalis]

You're welcome! I should probably do another one soon...

[@SimpMcSimpy]

Awesome work!

[@Ardalis]

Thanks a lot!

[@TrotterSoccer]

Nice video. Thanks a lot!

[@Ardalis]

You're welcome!

[@richardcoady6402]

Great video, and insight. Looking at you project structure if this was system had 100 entities for example etc would you split core out even more or would you leave as one large core dll.

[@steve-ardalis-smith]

What I'm doing as apps grow is reorganizing the Core folders so they're grouped into Aggregates, with relevant Events, Exceptions, Specifications, etc grouped in that folder. The basic structure of having root folders for Entities, etc only scales so far.

[@Jcat2forseven]

Hello, Was the UoW pattern ever implemented on the new version of the Ardalis Specification Repositories? On some complex processing the generic repo with individual calls to SaveChanges on the db context does not cut it. I already created a more specific repo for it but was wondering if any new UoW feature was implemented. I'm trying to use this the eShop project as a guide on my first .Net Core project. Thanks for this!

[@steve-ardalis-smith]

It's not. Really all you need to do is change the repo so that the add/update/delete methods don't call SaveChanges, and instead use the SaveChanges method that the repo already exposes.

[@Ardalis]

Thanks!

[@blu3_enjoy]

thank you mr ardalis

[@Ardalis]

You're welcome!

[@amrosaad9730]

Thank You.

[@caseyspaulding]

much appreciated

[@nicolasundiano8406]

Very useful explanation with an excellent example of a great architecture. If i want to add some properties such as FirstName, LastName and address properties of a user, could i add it inside ApplicationUser class in infrastructure? or there is a better way? sory for my bad english :)

[@steve-ardalis-smith]

You could, but it would be better to add them to a class in ApplicationCore, typically. Security is its own subdomain and changes frequently in many applications (local accounts, windows accounts, OIDC, OAuth, etc etc). If you have business logic around users of your system, best to model them in your domain model in Core and name it something appropriate (usually better than "User") like Customer, Member, Subscriber, Client, Employee, etc. Then on that entity, just include a UserId property that lets you map it to the security-specific type in Infrastructure.

[@nicolasundiano8406]

@@steve-ardalis-smith Hello thanks for the response. So, for example if i have some businessslogic with the user like a profile you recommend create a domain entity User with that profile properties and a identity user in the infrastructure layer only for auth things.

[@Ardalis]

Yes, keep the auth user separate from the domain type, if you can. Ideally give the domain type a domain-specific name like Author, Customer, Employee, etc. and just have it have a property UserId to tie it to the auth User type.

[@MohamedEmaish]

If you run the app from VS with kestrel not IIS express but choosing the app name in the dropdown beside IIS it will behave the same as command line and it will open with desired port

[@Ardalis]

Indeed, thanks!

[@cristianrambo9828]

Absolutely great video Question tho, on the vid you didnt anwser JohnCallaway question on chat, so I'll replicate in case someone else is interested: thoughts on passing in a mapper to the repository? Working on applications where I don't usually need all model attributes

[@Ardalis]

Sorry didn't see this earlier. I don't personally like passing a mapper to repositories because I consider the repository abstraction to be part of my domain model, and as such it should be returning my model types: entities. If I need to map to DTOs or ViewModels for the application, that's not the job of the repository, and usually I don't even consider it the job of the domain model at all. That's where application services, use cases, similar come into play, as a bridge between the domain model and the app (or just as logic that occurs in the app UI project). Hope that helps, and let me know if that doesn't answer your question.

[@Jigfors]

Hi Steve and thanks for this video. My head is struggling with the idea that we always go to the database to ask for the number of products in the shopping cart. What do you suggest to solve it? For example, if we have added a product to the shopping cart and then navigate to the first page, and we need to load the small shopping cart icon, do we really have to hit the database again to get the number of products and then update the badge next to the shopping cart icon?

[@Ardalis]

We need to store that information *somewhere*. You could (and probably should) cache it. You could decide to store the Cart in Redis instead of in your main transactional database. But I think it makes sense to persist it somewhere server-side rather than just keeping it in client state, and again, you have to get it from somewhere and I don't know what other options you might have. Do you have an alternative design to suggest? Thanks!

[@Jigfors]

@@Ardalis I may have been a bit unclear, but I totally agree that we should persist it somewhere on the server side. - Other would be bad, especially if we want customers to be able to continue on another device. However, I was thinking about something in between. Each time we add something to the basket, we persist it on the server, but also on the client side - using session/local storage or maybe a cookie? Then, you wouldn't need to query the server each time you don't add anything to the basket. Or would that be considered bad? Nine times out of ten, you may need to query the server side anyway, but I'm curious about the idea and would love to hear your thoughts.

[@steve-ardalis-smith]

@@Jigfors Personally I would probably cache the cart on the server (either in memory or redis) and clear it when the user modifies the cart or checks out. Most pages are going to require some database calls anyway, so one more (which could be done in parallel if you wanted) probably won't impact performance all that much. I don't think I'd recommend storing it in a cookie - it doesn't seem worth the complexity/performance tradeoff (to me).

[@Jigfors]

@@steve-ardalis-smith Actually, the more I think about it, the more I agree with that. In-memory would probably be the best choice for me at this time, with Redis as a long-term goal. Thanks for your answers and thoughts!

[@naasthikan]

can i convert it as Blazor server app ??

[@mustafabulgu5834]

The reason why you cant login around 24:35 is that, no migrations are run against the identity database. DB doesnt exist at that point.

[@SixOThree]

Why did you put the mediatr handlers in the same project as the web? Doesn't that defeat the purpose of using mediatr in the first place?

[@Ardalis]

You can put the handlers wherever makes sense. In this case I think they ended up in the web project because they depended on types defined in that project (it's been a couple of years since I recorded this and things have changed a bit in the meantime). Usually, that's the main constraint. In my current Clean Architecture template on GitHub/Nuget I've added an explicit UseCases project/layer which defines its own request/response types and is where all the handlers live. Perhaps that's closer to what you were expecting?

[@SixOThree]

​@@Ardalis It probably will be. I think I need to seek that out and examine it. Thank you.

[@fullstackdotnet]

will we get something like this on eshop on containers application? maybe a series? please? ^_^

[@TheVincent0268]

I found this: github.com/dotnet-architecture/eShopOnContainers

[@steve-ardalis-smith]

@@TheVincent0268 I think the OP was looking for videos on that project like I did for eShop. I'll try to do an update of eShop before end of 2021 covering new .NET 6 improvements but I don't know that I personally will have time to do anything with eShopOnContainers.

[@shikamaru271]

the public api is not working. i tried the process you described at 18:00 but it is not working. please help

[@kylian3399]

did you find a solution?

[@adnanahmed316]

How do we reference ApplicationUser in Entities?

[@steve-ardalis-smith]

You shouldn't need to. Its userId is used (to link the authenticated user to the domain model), but any other data you need you should store in a Core entity, not reuse the Identity-specific ApplicationUser class.

[@chadjboettcher]

@@steve-ardalis-smith Hi Steve. Thanks for pointing this out. I've been looking for a good example of doing this in practice. I've had the inkling that I should separate a login from a user in the system but wasn't sure of a good way to do it in practice. I need to be able to list users in a specific role in a select list and manage relationships that way. Should that be done using roles or some sort of user type in my user entity? If you know of any examples that you could point me to, I'd greatly appreciate it. Thanks!

[@steve-ardalis-smith]

@@chadjboettcher In many domains, auth is a separate concern, and so is kept mainly out of the domain model to avoid cluttering it up or creating distractions. In some domains, the identity components *are* the primary domain being dealt with (such as a user admin system), in which case of course you'd have domain model types for users, roles, privileges, groups, and what-have-you. If you find that you main domain is X but you also need some details from auth/identity, you can pull in what you need to your domain model, or you can use an anti-corruption layer through which to reference an external dependency that is responsible for the auth bits. If you're going more of the microservices route, then the latter would be your first choice, and you'd ideally have a separate service (or more than one) dedicated to the kinds of auth behavior you're describing. HTH.