Setting a default value -- presentation logic or business logic?

Question

I was wondering if setting a default value for a SelectList is considered to be presentation logic or business logic? For example, if a requirement is that an Employee cannot be saved without a Location, but 99% of the time the location that would be selected is a particular item -- say Atlanta. Because of this, the location SelectList should be defaulted to Atlanta when ever a entry screen for a new employee is displayed. Should I be defaulting the location in the model or in the view-model? One thing I realized is that the unit tests become awkward because in both cases, I'd be forced to test against a location that will always be present in production but I cannot create a unit test with my own test data unless "Atlanta" was in the set of locations being used in the test. I'd be greatful if you have any thoughts on this as well.

Answer 1

As with many such questions (subjective) the answer is: "It depends."

If the "default value" is a business default (say, a default location of a business location, or a default number of units on an order or somesuch) that's probably business tier. That appears to be correct for your specific situation here.

However, if the "default value" of your list is simply because you need some value to be the default, and you're just going to choose index 0, or just going to choose based on the user's location or system settings, I would think those would be presentation tier issues.

Answer 2

Because of this, the location SelectList should be defaulted to Location5 when ever a entry screen for a new employee is displayed. Should I be defaulting the location in the model or in the view-model?

It's business logic in your example, but that won't stop you from having your cake and eating it too in this instance. The model can specify a default value; the view then initializes itself with this default value.

In general, whether or not something is "business logic" or "presentation logic" depends on whether it concerns the domain or not. For instance, setting the earliest year in a date drop-down to, say, 1900 is probably a presentation concern. But it could also be a business concern, if the system isn't designed to accept dates earlier than 1900.

One thing I realized is that the unit tests become awkward because in both cases, I'd be forced to test against a location that will always be present in production but I cannot create a unit test with my own test data unless "Atlanta" was in the set of locations being used in the test. I'd be greatful if you have any thoughts on this as well.

With the strategy I mentioned above, unit-testing is easy. Simply verify that:

• the model provides a default value
• the view accepts this default value
• the view initializes itself to this default value
• the view has the appropriate behavior whether or not the model supplies that value