|
> From: Pete Hall > > You lost me a little here. Aren't you agreeing with John? Doesn't a view > that implements something like the CASE statement he suggests align itself > well with your concept of a data deployment layer? Wouldn't a group of > views be one way to implement it? I'll bet a modifiable trigger > buffer on a > read trigger be a great help in implementing such a system. I'm not sure > how you'd get from an integer enum to a string value. Maybe THAT would > require a view. I have absolutely no problem with SQL in the data deployment layer. My concern is that the CASE statement John was proposing is more than likely going to be used up in the presentation layer, in order to avoid IF/ELSE logic. I think this particular CASE statement crosses too many tiers. Instead, I suggest something like this: Data Deployment: SQL SELECT statement Business Entity: One or more data deployment calls to populate entity Business Logic: Convert attribute to text ID Presentation: Convert text ID to human-readable Business logic converts the attribute to a text ID (such as a message ID), which the presentation layer converts to the appropriate text based on the locale. The conversion to human-readable could be done in the business logic layer, provided the business logic is able to query the job attributes and determine the user's locale information. Alternately, you can skip the text ID and convert straight from attribute to human-readable in the presentation layer; that really depends on the application. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.