database access not allowed in certain classes
Wed, 2008-07-09 15:12 — jurjen
| Project: | Prolint Issue Tracker |
| Component: | Rules |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
One rule to enforce application layering: the DataAccess layer is allowed to acces the database, the business logic layer is not allowed to access the database directly but should delegate that to the DataAccess layer. So, create a rule that warns when a class tries to access the database when that class derives from "BusinessEntity" or from "BusinessTask" or from any other class in a configurable list of classnames. Or the other way around: no class can access the database except classes that derive from "DataAccess".
- Login to post comments
Comments
While a rule like this has
While a rule like this has some obvious appeal, it's difficulty is in finding a sufficiently configurable way to apply it. Plus, it may be that it is only marginally useful. After all, if one has an old style development environment with everything mushed together, then it is going to be very hard to say what should or should not have data access, but if one has created an environment which is structured around OERA principles, then one would have to be really not paying attention to put data access where it doesn't belong. I.e., if one is conscious enough to define a class as inheriting from BusinessEntity or some such and one knows that means that any data has to come from some other object, one would really not be paying attention if one coded a READ or QUERY. And, one should probably be compiling it in a session without a database connection.
So, good idea, but I'm not sure how necessary it is.
I might note that having one's development go to and from UML creates another way of looking at this issue since diagrams of the components should conspicuously show whether there were inappropriate connections. I.e., with or without UML, maybe we should be considering another structural level of review. Use ProLint for code quality focused on the individual compile unit, but then use something more structural or diagrammatic for the relationships between units.