I am trying to decide how (or whether) my
Data Access Layer should deal with existing security and integrity protections on the database. The architect in me says that
separation of concerns is a priority and duplication of duties is wasteful so I should leave the database to handle access control and let the
Object Relational Mapping be a dumb middle-man between the
business logic and the
persistence layers. But the DBA in me really doesn't like the idea of creating models that allow other developers to attempt to handle the underlying data in ways that they should not (as defined by constraints, relationships and account security on the database).
How "smart" should my DAL be? Should my DAL take into account access privileges (such as who can read/write) to create an object-oriented accessible version of my persistence layer? Or should it be a true pass-through and should I expect my business-layer to respect security to which it may not have immediate visibility? More probably something in-between?
In other words... if I have a database account which only provides
SELECT (read-only) rights to table
MYTABLE, should the
Data Access Layer object for
MYTABLE reflect these permissions in what methods are allowed to be called against this model? What about when I have a single entity which could be accessed in different ways depending on which account (or service) is hitting it? Should I have multiple models of the same underlying data?
If you cannot tell from my wording above, I would prefer to have a smarter DAL that ensures my database controls are being at least somewhat respected (without the need to throw a bunch of runtime errors). But I don't know where to draw the line between "business logic" and "data access logic" and I hate the idea of duplicate work.