liveBook · Manning

Separation of concerns

As explained in Building Web APIs with ASP.NET Core

Separation of concerns is a design principle that partitions a system so distinct responsibilities are handled independently.

Separates distinct responsibilities so each part of a system can be handled independently. In REST, this means keeping the user interface and data storage concerns apart. section 1.1.4

Applying the principle supports several practical system qualities:

  • Improves portability by allowing clients and server-side data concerns to evolve separately. section 1.1.4
  • Keeps implementations simpler to build and maintain. section 1.1.4
  • Contributes to system scalability and modifiability. section 1.1.4

Browser and web application

A browser acts as a client with a separate role from the web application and does not need to know how that application was implemented. This boundary illustrates separation between interface and data-related responsibilities. section 1.1.4

How Building Web APIs with ASP.NET Core covers it

How deep it goes
Defines the principle and its benefits, then applies it conceptually to REST without developing a detailed implementation.
Examples
Uses browsers, web applications, user interfaces, and data storage to illustrate separated client and server responsibilities.
What you can do after
Evaluate whether a REST API keeps client-interface responsibilities independent from server-side data responsibilities.
How it connects
Connects separation of concerns with REST, client-server architecture, portability, scalability, and modifiability.

Also explained in

Compare how 22 books explain separation of concerns →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building Web APIs with ASP.NET Core. The section links point to the parts of the book it draws on.