| This post was kindly contributed by SAS from Out in Left Field - go there to comment and to read the full post. |
Good systems practice is to have demarcations between systems layers. This involves separation of the following layers (at a minimum):
Application
Business logic
Data access
Data
SAS programmers though tend to muddle all together:
libname indata …; <-- Data Access
data mydata…; <--- Business Logic
ods html; proc report…; <--- Application Layer / UI
A better way to handle is to treat all layers as standalone and get them out of each other’s space. The easiest way for a SAS coder to accomplish this is to use macro libraries to get it all started:
%GetFinanceData() ;
%DetermineProfit() ;
%OutputResults() ;
However, even this is constrained since everything is called together and a single program controls what happens top-to-bottom. Rather than doing the final piece as a part of the batch job, consider doing it on demand and perhaps through other means:
%GetFinanceData() ;
%DetermineProfit() ;
…wait until use requests information….
Get information on demand and make the presentation logic extraneous to SAS. Someone could even keep it in SAS ODS but the idea would be to pull it out to an application layer that is completely separated from how the information was formulated.
SAS programmers would be better off putting in extremely strong lines of demarcations between layers. This makes code easier to maintain, easier to change, and easier to understand.
Longer term, web service calls will simplify this even more but the concept of processing silos can be done now. Break your code apart so everything isn’t glued together so tightly that code reuse is hard and code libraries are non-existent or little used.
| This post was kindly contributed by SAS from Out in Left Field - go there to comment and to read the full post. |