Deisgn Pattern: How to map UI requests to Controllers to Services?

Question

I'm learning about writing WebApi design patterns.

I am trying to create a simple CRUD web app with ReactJS UI and C# .NET CORE webapi with sql backend.

Articles show that specific Repositories are a direct reflection of the tables inside the DAL. And the services layer handles the domain objects and draws entities from the repositories layer. Those same articles also show the controller being designed for changing entities from just one data table in the DAL. So basically, an Employees table inside the DAL would have an Employees Service and an Employees Controller. Is this the correct interpretation?

In my example: I am confused about which path is the proper way to do it. I have a form that needs to get, post, put records from two different tables (Employees and Devices) in the DAL.

So do I build a single controller that can handle this form's requests (with JSON obj) or do I build two controllers and code the UI to speak to two separate controllers (one for each table)?

In this example, I skipped the repository layer because there's not much logic to need both a repository and service layer.

Please see the two alternative diagrams:

Multiple Controllers	Single Controller

Answer 1

So basically, an Employees table inside the DAL would have an Employees Service and an Employees Controller. Is this the correct interpretation?

It is one interpretation, but it is not the only one.

Yes, when you make a REST API, your exposed API resources tend to represent the same as your DAL entities (even if their content is slightly different). This again is not a given, but it is common.

But that doesn't mean that this is the only way to do it. At each level, you are able to merge more than one item, when that layer needs to represent the combined grouping.

For example, while you may store people and their addresses in separate tables, it's possible that your domain logic sees these as a single aggregate where Person is the root and Address is a sub-object.

Based on your question, I suspect you may not have heard about DDD yet, which is what this is referring to. The main thing to understand here is that this is one example of how things work differently from your interpretation: the domain (= services layer) works with person/address as a single group of information, but the underlying data stores people and addresses in separate tables. Therefore: one service which connects to two repositories.

Similarly, this kind of grouping could happen on the Web (= controller) layer. Even if you have separate Person and Address services, it's possible to have a single web request which contains data of both people and addresses, and therefore this controller will connect to both a Person service and Address service.

There is no one-size-fits-all solution here. You have to structure your application based on your requirements. Figuring out the right structure is the art of (senior level) software development.

You didn't really add the kind of information that you'd need to distinguish whether this grouping happens on the service or controller level.

---

In this example, I skipped the repository layer because there's not much logic to need both a repository and service layer.

If it's only omitted for this example, that's fine. But don't use this as an excuse to actually merge your services and repositories in a codebase! The business layer (services) and data layer (repositories) each have their own responsibility. Even if they're light on custom logic and mostly act as a pass-through, developing those layers individually will significantly help your code maintenance down the line.

The reasons for skipping the distinction between data and business layers are few and far between, and developers have a habit of wrongly trying to cut this corner.