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

You’re welcome!

Thanks!

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

Thanks!

Glad it was helpful!

You're welcome!

You're welcome!

You are welcome

You're welcome!

Thanks!

Indeed, thanks!

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?

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

You're welcome!

Thanks a lot!

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.

You're welcome!

Yep, thanks for the catch.

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.

Thanks!

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

@@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.

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.

@@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.

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.

Probably. Perhaps by now you have!

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!

@@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.

@@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).

@@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!

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.

I'm still doing this (organizing domain model around Aggregates) and it works great!

You're welcome!

did you find a solution?

eShopOnWeb has been updated to net8 and is now hosted at github.com/nimblepros/eShopOnWeb, for anyone looking at this today.

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.

@@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!

@@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.

Probably but I haven't personally tried that.