CRUD for hierarchical data in ASP.NET - single view/controller vs. separate view/controllers?

Question

I'm trying to develop a CRUD feature for an ASP.NET app that lets me manage customer information. Each customer can be subscribed to one or more services, and each service can have one or more terms.

I'm struggling with the same types of questions for both the frontend and the backend.

I'm trying to decide whether to manage this information in one view/controller, or to split it up into separate views/controllers. I'm considering three options:

1. One view/controller for everything (customers, services, and terms). This option makes sense to me because the terms are a properties of a service and services are a property of a customer, they don't have much significance on their own.

2. Three separate views/controllers (one for each model). This option is more organized.

3. One view/controller for customers, and a separate view/controller for services and terms. This option makes sense as a compromise because the terms are more closely related to the services than services are to customers.

Even though I realize that asking about the frontend and the backend are two different questions, I'm lumping them together because I have the same questions for the same reasons about both. Even so I'm completely open to the answer being different for the frontend than it is for the backend.

• Ben Cottrell: Which of these options would result in the simplest logic/flow in the front-end/UI, or indeed the fewest number of separate HTTP requests from your front-end? As a general principle, I would focus on functionality and requirements in the front-end to drive the design of the service API, prioritising the needs of the client above all else wherever possible, leaning toward whatever API results in the easiest/simplest front-end implementation (taking care to avoid the UI needing to orchestrate multiple separate HTTP requests to complete a single behaviour or display a single page)
• Doc Brown: Why are services a property of the customer? I would expect a set of services to exist independently from any customer, and hence there should be a separate view for services (maybe with terms). The customer could have a subscription to a service as a property.
• Doc Brown: ... voting to close ("needs details or clarification"). I will be happy to revoke my close vote after I get a satisfying answer to my question above.

Answer 1

I like Option 2

Three separate views/controllers (one for each model). This option is more organized.

Simply because it gives a clear definition what is the pattern to add an endpoint in the future as the application grows. You could have an base implementation that the three endpoints inherit from initially and change over the course of the life cycle of the API as you discover deviations from the base

• Doc Brown: Sorry, but if I got this right, this is standardization for the sake of standardization, apart from any sensible UI design. I am sure this should not be the guiding line here.
• frictionlesspulley: That was not my intention either. I was looking at it as a means to communicate without explicit documentation how someone can contribute to the project. If that implicitly entails following a "standard" I am not averse to it. Cheers!
• frictionlesspulley: Btw I did answer the question specific to the example OP gave thinking customer / services and terms thinking they were independent entities. I should have been more explicit