When passing data between the backend and the frontend (through the controller), it can be quite seamless on its own, however, the process can come with a lot of security risks if there are no checks and balances in place. There's a lot of danger involved in letting end-users send data directly to the database, it's risky because of things like SQL injection attacks among other attacks. Because of this, we as software engineers come up with fail-safe.

Fail-safe like input validation, error handling, use of conditions, stored procedures, among others, helps to prevent situations where end-users can make mistakes or malignantly try to bring down a software solution. As a result of further investigation into cybersecurity (which largely influences how software development is done), DTOs were recommended as an added security layer to ensure that end-users can't interact directly with the database.

DTO EXPLAINED

If you read yesterday's post about MVCs, you're probably thinking that the Controller and the Model stand between the end-user and the database, however, these structures are more of pipes than fail-safe, yes, they can filter data but it's not a one-stop solution. DTOs stand for Data Transfer Objects and exist to ensure that the model classes aren't totally exposed to the end-user. DTOs are used to create a layer that is similar to the model layer but doesn't expose everything the model has to offer.

A RELATABLE EXPLANATION

With DTOs, developers can cherry-pick what properties of the database will be exposed to the end-user. Typically with model classes, the end-user has total access to the entire class when you allow end-users to interact with the class. Recall that a database looks a lot like an excel spreadsheet and the class represent a table in the spreadsheet while the properties of the class represent the columns in the database table, if I give you an Excel sheet, you have access to all columns in the Excel sheet.

With DTOs, it's like handing you an Excel sheet with a couple of the columns locked and inaccessible to the point that you can't even see the content of those columns, you can't edit them neither can you see the content of that column, but it's there and it gets data too. DTOs aren't foolproof, however, they make it possible to change the structure of the model class without harming the entire software solution, because the DTOs are what interact with the end-user, a little change will be made to the DTO and everything will work fine.

FINALLY

Adding DTOs to a software solution can be stressful for junior software engineers as one can easily make mistakes that can be very hard to fix. With frameworks like Microsoft ASP.NET, there are extensions that can scaffold the DTO from the model class. There are a lot of things to keep in mind when developing software solutions this is why developers have problems with clients that on a whim want new features to be added to the software solution when production is already underway 😂.