Should translation of a user specific 'end date' to a DateTime be done at the Presentation Layer or Business Layer?

Question

The system has a page where the user can search through items by specifying a start date and end date. These are plain dates (Without the time component). For the user it seems most intuitive for the end date to be inclusive (so include all items for that end date as well).

The CreateDate of the items however does contain a time component in the data store. In practice this means that we need to translate this timeless end date to a 0:00:00 hour date for the next day. This way we can write the following query:

SELECT *
FROM   Items 
WHERE  CreateDate >= @STARTDATE
AND    CreateDate < @ENDDATE

Transforming this end date is as easy as writing this line of code:

endDate.Date.AddDays(1);

Nou my question is:

should I consider this last line of code business logic and should it be placed in the Business Layer, or should I consider this line a piece of 'model binding logic' and should it be placed in the Presentation Layer?

When it is placed it in the BL, this means that the BL knows about the presentation layer, since the way the value is supplied is something that is interface specific. On the other hand, since the operation is defined as a DTO in the business layer, I could also see this object as interface that should be convenient for the presentation layer.

This question might even be philosofical in nature, since there are probably multiple ways to look at this, and the actual conversion code is trivial. I'm interested to hear why you think it should be placed in one layer and not in the other.

I don't expect the application's architecture should have any effect on the answer to this question. But to give a more complete picture, the architecture is based on commands and queries and the presentation layer creates a query object that are handled by the business layer. The PL code would typically look like this:

public Action Filter(DateTime start, DateTime end)
{
    var query = new GetItemsByStartEndEndDateQuery
    {
        StartDate = start.Date,
        EndDate = end.Date.AddDays(1)
    }

    var items = this.queryProcessor.Handle(query);

    return this.View(items);
}

Or when possible, (MVC) model binding is used to simply model bind the command and query objects (which is very convenient):

public Action Filter(GetItemsByStartEndEndDateQuery query)
{
    var items = this.queryProcessor.Handle(query);

    return this.View(items);
}

Would your answer change when there are multiple users involded (a WCF layer and a MVC layer, for instance)?

Answer 1

There should be a contract for the semantics of the service exposed by your business layer, and probably automated tests for that contract.

This contract should define how the input arguments are interpreted and validated, for example:

• What is the result if StartDate > EndDate?
• What range of dates is acceptable (e.g. what about dates earlier than 1/1/1753 with SQL Server)?
• Are input parameters allowed to have non-zero time of day components, and if so how is the time of day handled (truncate and use date only; throw an exception if the caller includes a time of day component; or allow caller to specify a range that includes a time of day component).
• Is the range exclusive or inclusive?
• How are time zones handled (e.g. date parameters with Kind = Local, Utc or Unspecified)?

If this contract doesn't match the way the presentation layer wants to get input from the user, then it's OK for the presentation layer to do the mapping to match the contract.

And of course, if the contract does not match the way the data access layer expects the date range, the business layer can do the mapping to whatever the data access layer expects.