Another consideration is extensibility. For example, we have developed some
services that run constantly, and maintain logs. These logs are files that
contain various status data. Originally, we were required to be able to send
reports from these logs to various people connected with the project.
Initially, I wrote a class that parses these logs and builds strings for
emails containing the reports.
Then we received a requirement that there should be a web site where
up-to-the-minute reports could be seen. I suddenly realized that I had not
planned for this. So, I built serializable log classes that contain the
status data necessary to do any type of reporting. These classes are
instantiated by the service when it runs, and data is stored in them until
each job finishes. At that point, the classes are serialized into log files
(as XML). The ASP.Net web page can then open these files, and use an XSL
Tranform to convert the data to nicely-formatted HTML. The formatting is
removed from the classes, and if we want to change the look of the reports,
it can all be done by modifying the XSL document and the CSS style sheet
used. In the future, if we need these reports formatted any other way, we
can just write XSLTs to do the formatting. And each class has a ToString()
overload to provide the "plain text" version for emails, or can use an XSLT
to do HTML-formatted emails.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.