Some time ago, I mentioned that my next post would be about the Separation of Concerns (SoC) principle in software development. This topic came up during a job interview, where I found myself in a debate I couldn’t quite articulate my stance on. Was it nerves? Adrenaline? Or simply the pressure of having a senior developer, a team lead, HR, and a department leader sitting across from me? I’m not sure. But here’s the code that started the disagreement :)
<img src="https://media.daily.dev/image/upload/s--9B4JKEN3--/f_auto/v1738286227/ugc/content_4cc6f5d4-3b2b-4019-b63d-84a8f6e505e7" alt="Screenshot 2025-01-31 021644">
The debate centered around why I map the request model to a DTO and then an entity and on the way back a response model, instead of passing it directly through the layers. The request model is a dto, their approach was to reuse the request model across layers and return a dto back to the client I assume now, I did not ask back then anyhow, while I strongly disagreed. However, in that moment, I struggled to articulate my counter-argument effectively and I certainly didn’t want to come across as a stubborn candidate.
After the conversation I reflected and went into research mode, and this time ill stand my ground :)
Here’s why passing request models directly through layers is a bad practice and why DTOs matter in a well-structured application.
<img src="https://media.daily.dev/image/upload/s--t2bn_AH0--/f_auto/v1738308590/ugc/content_968315df-2870-4c9b-a3d1-4a925d6265b9" alt="content_e5ce627d-993d-4ba4-af40-8db61c0ed257">
In a traditional N-layer pattern software, where data flows from top till bottom, if we structure our application in Separation of concerns like this Api-Services-Dal. We know or I’ve been taught that returning a entity to the presentation layer ( API ) is bad practice and lazy, not to mention security aswell.
If we keep that thought shouldn’t we also apply that reason if we reverse it? we shouldn’t pass the dto from the presentation layer all the way down to the data access layer.
but lets get one thing straight, even thou the model that is a parameter in a endpoint is technically a dto, we should be explicit and call it a request model, that way we can distinguish where this model reside( in the presentation layer/controller ) and whats its purpose( concern ) is, to represents how the client communicates with the API it should only be used here in the controller.
We should then map this request model to a data transfer object when passing it down to the service layer, to decouple the request model from the business logic which reside in the service layer.
Because the request model is tightly coupled to how the client expects to interact with the system. The business logic should remain isolated from these external concerns. Furthermore this reduces complexity by enforcing clear boundaries between layers. Otherwise, a change in one layer ripples through all layers.
If we skip mapping and directly pass the request model, the API layer bleeds into the business logic layer, violating the Separation of Concerns, why have SOC to begin with?
I believe many developers know the SoC principle, but enforcing it in real-world applications is harder than it seems. Spreading awareness and having discussions like these help strengthen our industry standards.
If I’m wrong? Please do correct me. Lets grow together!

All about .NET, C#, and ASP.NET Core. News, tutorials, articles, projects, and more. 

.NET

The author's reflection on the Separation of Concerns (SoC) principle in software development, sparked by a challenging job interview. They discussed why passing request models directly through layers is considered bad practice and the importance of using Data Transfer Objects (DTOs) to maintain clear boundaries and reduce complexity. The post emphasizes the importance of implementing SoC properly to enforce isolation between layers and enhance security.

Separation of Concerns Principle: A Reflection after a job-interview

I agree with you. Isolate the business layer and APIs could help the application easier to change

People that find this interesting should check out Clean Architecture. Learning about that architecture made many of these principles click for me. More than just “bad vs. good practice” etc.

I agree to. It’s not a good idea to couple the request model with the business model because how the client queries for data might change over time, tight coupling means if you have more than one client querying for data using different patterns affecting your business logic, you might need to modify the logic inside the controller depending on user. Just decouple