Should a custom "end date" be translated to a DateTime at the presentation level or in the business layer?

Question

The system has a page where the user can search for items by specifying a start date and an end date. These are simple dates (without a time component). For the user, it seems most intuitive for the end date to be included (so include all the elements for this end date as well).

CreateDate elements, however, contain a time component in the data warehouse. In practice, this means that we need to translate this perpetual end date to 0:00:00 o’clock the next day. Thus, we can write the following query:

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

Converting this end date is as simple as writing this line of code:

 endDate.Date.AddDays(1); 

Question:

should I consider this last line of code business logic and place it in the business layer, or should I consider this line as part of the "model binding logic" and should it be placed at the presentation level?

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

This question may even be philosophical in nature, since there are several ways to look at it, and the actual conversion code is trivial. I am interested to know why you think that it should be placed in one layer and not in another.

I do not expect the application architecture to influence 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 is processed by the business layer. PL code will usually 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, if possible, model binding (MVC) is used to simply model the binding of command and query objects (which is very convenient):

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

Will your answer change if there are multiple users (e.g. WCF layer and MVC layer)?

Answer 1

There should be a contract for the semantics of the service displayed by your business layer, and possibly automatic tests for this contract.

This contract should define how to interpret and validate input arguments, for example:

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

If this contract does not match the way the presentation layer wants to get input from the user, then for the presentation layer it’s OK to match the contract.

And of course, if the contract does not match how the data access layer expects a date range, the business layer can match what the data access level expects.

Answer 2

I usually put this line of code, and others in the business domain or domain service.

It:

 endDate.Date.AddDays(1); 

Or:

 endDate.Date.AddDays(3); 

This is a business problem and should be at the business level or in the domain service. Given the correct decoupling of the application architecture, you can simply change and redeploy the domain level without affecting other levels (for example, the presentation level).

Answer 3

The main thing for me is the fact that the dates entered on the page should be translated into timestamps differently depending on whether they represent the beginning or end of the time interval. That is, and not just a matter of two different conventions that are directly related to each other, there is a semantic transformation to execute.

In my opinion, such transformations belong to business logic. However, note that if the user computer is in a different time zone from the server, the problem may not be as clear.