Architecture: Are form default values considered business logic and where should the logic to calculate them be placed?

Question

An example of default form values on a search form might be:

Start Date - Today

End Date - The last day of the next month

Obviously, these are fairly simple examples, but default values can get a lot more complex and potentially rely on "real business logic" (from an entity).

A search form is a good example because it does not have a corresponding entity.

So what is a good way to encapsulate complex default value logic? Perhaps the view model? Maybe create a new business object? Or should it just go in the view/controller responsible for rendering the form?

This is an ASP.NET Webforms application and my particular problem is where to put the logic to decide how the feed back regarding an event is categorized.

Answer 1

StartDate and EndDate of what?.... the school year? Ok:

public class SchoolYear {
     StartDate = DateTime.Now;
     EndDate = new DateTime (2016, 6, 23);
}

Object Oriented Programming is about, well, objects: Put properties in a class to appropriately describe/define what it is. Write methods against those properties to describe/define what it does.

As for "complex default logic". "Complex" or "default" notwithstanding, put the logic with the properties it goes with, hence both in an appropriate class. If "complexity" means a need for different class/objects to interact, OK, but each class/object is responsible for doing it's own thing.

A School Year certainly will not have the teaching staff defined in it, however a Teacher may well have his/her Calendar initialized with the SchoolYear.StartDate.

Answer 2

I asserted that default values are business logic and should be tested as such in a recent code review. It's not hard to pull the initialization logic out into whatever component owns "presenting" your view. In essence, ask yourself why a default value should be treated any different from a.. I don't know.. "normal" value. If you concede default values are special, you are willfully ignoring logic just because it seems to be trivial.

Answer 3

In a MVC type web application, default values being submitted with a form request should generally be placed in the view directly. This is to say that the controller shouldn't care what arrives, so long as the parameters are valid (and as these things go, it is always a good idea to check user input).

However, it is also true that default values can get complicated as you mentioned. Say that you want the default starting date to be when an order was placed. If this were a web application, of course you don't have this information readily. You'd have to pass it to the page so that the page could use it as a default value.

In this case, I would argue that you should allow the possibility of not submitting a starting date. The server, upon seeing that a starting date isn't provided, would provide the default. These types of parameters, unlike those which are constant or don't depend on the state of your model, should be considered business logic and should have their defaults taken from the model portion of the application. If done right, the user will not have many parameters with defaults, but rather only a few mandatory parameters with the possibility to add additional parameters. This makes your request much more organic and you have less validation to worry about, thus also making it more robust. In addition, your view will become more intuitive to use.

Answer 4

This is a very very broad question... Too broad to really answer well...

Are we talking about things like days of the week? are we talking about things that matter only to the UI, and the Business Logic doesn't care about? are we talking about values that arise from real Business Logic?

1. Some default values come directly from Business Logic. Eg. employ rank, is a product a fruit or a vegetable, preferred payment method. usually these values come from a predefined set, and can change with time and requirements. These values and their deaf ult should probably come from data i.e. a Data Base. which will leave them free to easily change, and the UI won't care. Sometimes these values have more clever logic behind them, for example the "Waze" app offering you to drive home, or to work depending on where you are.

2. Sometimes default values are only relevant to the UI and user usability. If I have a method like SearchSomething(Time start, Time end) in the BL (business layer). I couldn't care less about the values i get, and maybe different clients would like to have different defaults? So it's something that should be determined in the UI, but I wouldn't want to soil an MVC view with this. I think it's more appropriate as a part of a model.

3. Some default values are so common and trivial it doesn't matter where you put them. you could naively put them in the UI, in the view itself, or in some Constants class in the BL. Depending on what you actually need...