The one problem; that is very common in team projects is existence of “zombie objects”. I weblogged about how one can trace such objects with in database layer; but what about business layer? Here is one approach that we try to follow.
We establish interfaces for data access layer; say IDBLayer, if there exists multiple client application; eg a web application, and a windows service; then we establish separate interfaces; something like
IWebDBLayer : IDBLayer
IServiceDBLayer : IDBLayer
Then in implementation classes; all the SQL queries / procedure names are written either in external files (config or xml files) or at least constants are defined.
With these two things; we can create a list of database objects that our middle layer needs an access.
On the database side; we expose only required objects; all other objects are encapsulated. For encapsulation; we use database security; i-e we setup different logins for development and application. The login for application is given only required permissions.
Just a short tip; for SELECT operations; we create VIEWS and for UPDATE/DELETE and INSERT operations we create stored procedures. We try not to expose the base tables.
Doing this; we can create a list of database objects that are exposed to the middle layer. Now comparing this list with the above list; we can easily identify the “zombie objects”
I have just finished doing one review which involved steps to identify such “zombie objects”. I just wish that this can be made automated somehow…