[bob1029]

> To start off, you need a data access layer. This is non-negotiable for well-structured applications to properly secure your data. Scattered SQL queries across your codebase will most likely lead to unmaintainable authorization, even data leaks.

Super hard disagree with this.

Much of the pain and suffering I deal with in legacy codebases can be attributed to someone attempting to force the entire product to use one logical view of the data. This typically manifests as a single folder full of ORM types. "Models", "Entities", etc.

Virtually all problems can benefit from taking more targeted and nuanced views of the underlying data. This is only possible when the original call site is directly responsible for composing the SQL query.

You talk about authorization but I think this is confounded by the strategy of one middle tier handling all data access. Now, you've got to move the auth code away from the business logic that justifies it into a box that's way too smart to be labeled "Data Access Layer" by this point.

All this really accomplishes is smearing your BL across a bunch of DLLs.

[robertlagrant]

> Much of the pain and suffering I deal with in legacy codebases can be attributed to someone attempting to force the entire product to use one logical view of the data.

This seems like a non sequitur. Data access layers don't require one logical view of the data.

[yawnxyz]

Yet at most mature-ish orgs this ends up happening... it's such a pain to deal with