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.

  • 1
    Can you provide a little more detail? Is this a web application? MVC? Commented Apr 17, 2015 at 15:22
  • This is not regarding a specific problem I am having, it is a hypothetical design question. Answers may assume what they want as long as the response is generally usable. Commented Apr 17, 2015 at 15:24
  • I am not sure why this question is getting down votes, it is a general architecture question which is on topic for Programmers. Please comment with issues so that I may improve the question. Commented Apr 17, 2015 at 15:34
  • Can you provide an example of what you mean by "complex default value logic?" If it's something like a "balance forward," it's just ordinary business logic. Commented Apr 17, 2015 at 15:50
  • Use the last day of the next month. It is trivial today, but 30 years ago this would have been quite complicated to come up with. Commented Apr 17, 2015 at 17:29

4 Answers 4


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.


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.

  • 1
    While this is a very good answer, it only addresses part of the question. So where do you extract this logic to? Commented Apr 17, 2015 at 17:30
  • "It's not hard to pull the initialization logic out into whatever component owns "presenting" your view." Commented Apr 17, 2015 at 18:08
  • @TheCatWhisperer but perhaps what you're hinting at is that default values might even be too complex to be considered presentation logic. In that case whatever component owns providing your presenter with data should be able to coerce the data into what ever format is needed at the UI layer based on its internal business logic. Commented Apr 17, 2015 at 18:12

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.


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...

  • Where would you put logic for the last day of the next month if you did not have access to the wonderful .Net DateTime object? Commented Apr 17, 2015 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.