Part of a system I am working on manages some securities information (stocks, bonds, etc…) and business rules specify certain fields be displayed only in all CAPS (stock symbols and CUSIPs for example). Users will have to look at data displayed on the screen as well as perform create/edit data-entry operations.
Where is the best place to deal with this?
1. Presentation layer only
user enters “ibm” as stock symbol, stored in database as “ibm”, converted to uppercase when displayed in app (“IBM”)
2. Convert to CAPS before storing in DB
user enters “ibm”, model class converts to uppercase and sends to database, stored as “IBM”
Something like a custom setter:
private string _StockSymbol;
public string StockSymbol
{
get { return _StockSymbol; }
set
{
if (value != null)
value = value.ToUpper();
_StockSymbol = value;
}
}
3. Convert to CAPS at DB
user enters “ibm”, database insert query converts to “IBM” (for example, using the UPPER function in SQL)
The end result is the same for the users – they see their data in all CAPS and the system doesn’t care if their data input is in the proper case or not. The most “MVC compliant” answer seems to be #1, but if this data will never be used in any other format other than all CAPS, I would argue it should be validated as such before being stored in the database. That then becomes more of a controller or view model concern, right?
I’ve heard people speak about accomplishing this client-side with Java (and even CSS), but that seems like a very poor solution.
I think the question is language/system-agnostic, but if it matters, I’m using MS SQL with Entity Framework/ASP.Net MVC.
What I’m scratching my head over is whether or not a presentational business rule like this should influence how the data is stored in the DB (CAPS vs no CAPS). The application doesn’t care if the stock symbol IBM is input as “iBm” or “ibM” but it seems wrong to store the data like that (it will only ever be used/displayed in CAPS).
Would you consider this a data validation issue to be handled at the controller/model level, or a presentational detail to be handled only at the view?
4
I think it pretty much comes down to whether the uppercase-ness is a display requirement or a property of the data itself.
To take a different example, if it was necessary to display a name with the surname uppercase for emphasis, I would capitalise it in the output UI, as in your (1). This is a display requirement as surnames are not ‘naturally’ uppercase – other views might use the original capitalisation.
To get back to your case, although I’m not an expert on stock symbols but as far as I understand it they are always uppercase. That is, a stock symbol is inherently uppercase, and so I would check this as part of the input validation, as in your (2).
1
I think it’s good to have the same data always formated the same way in the database.
There are many cases where an application might care about whether something is formatted as "iBm" or "ibM". After all "iBm"!="ibM"
A developer who asks the database for the name of a stock can reasonably expect that the same stock is always formated the same way. Especially if a lot of data is stored in uppercase, his application might have bugs if a few examples don’t come formatted as expected. That might introduce bugs.
The database therefore shouldn’t allow you to add data that isn’t correctly formatted, so you should solve the problem at the database layer.
If some values are always in upper case I would store them in upper case for the following reasons:
- To reduce the number of conversions in the code.
- To decrease the
possibility that future updates to the code will not take the
Business Rule into account. - To make troubleshooting easier. If
somebody in the industry is used to see certain things in upper
case, it will make her live easier when debugging/troubleshooting if
values show up in familiar format.
Having said that, I would convert on entry and validate/convert if necessary on the backend before saving to the database.
2
I would store them always in lower case. This way you can assume you are always looking in DB for lower case word (in this particular case). The key is to be uniform in the DB. This avoid the issue Christian described.
This kind of thing are display issue only so you should format when you show the data to the user (#1 in your question). This offer more flexibility, if for X reason somewhere you would need to display those value with a different format then you could easily.