Tag Info

New answers tagged

0

Maybe you are missing a layer. Without knowing the details of your application (requisites, architecture, etc) I would do something like Client (whoever it be) -> Application Service -> Domain Model The application service layer is allowed to interact with the repository and the domain model containing the business logic. So you can have something like: ...


0

Why should I do it? So we create a form, and we'll have an endpoint where that data can get submitted. Which means anyone can submit data there and see what happens. So we need to validate on two things: that it's being submitted by a user (which .NET will handle for us), and that they're submitting data via a requested form and not just willy-nilly ...


1

A few of your cases above suggest throwing an exception when a validation fails. This is typically not recommended as exceptions should be reserved for exceptional cases (e.g., service not available, timeouts, etc) and not normal program flow. Also, exceptions are typically expensive operations. Validations are expected to fail when the conditions are ...


1

You are leaving out the possibility of restricting the input in the database. If there can indeed only be one review of a particular movie by a particular user, that should be a database constraint. If you do that, then your concern is how to handle a failed attempt to insert a second review -- how does that get reported to the user.


3

In a DDD (Domain Driven Design) application using a conventional layered architecture, business logic goes into the domain layer. Now, please note this layer does not only contain the domain entities (Movie, Review), but also domain services (like a ReviewService class) and repositories. So, ReviewService is a business class as well. Your concern about ...



Top 50 recent answers are included