My application is currently quite a mess and I'm trying to untangle it all. My current idea is that I should have 3 separate layers:

  • data layer that knows how to keep stuff in database (and handle data schema changes, so it's not really that trivial)
  • domain layer (is that correct name?) that does all the magic changing the objects and processing events triggered by user requests
  • presentation layer that knows how to show to user only what that user is allowed to know (some data is hidden from user just because)

My initial idea was that having a data object I can build domain object from it, then build a view object from that one and then serve it to user. However I'm now thinking about building view object directly from data object.

  • If the user just queries some information, I fetch the data from database, get the nice presentation of it, then serve it to user. Not touching the domain layer at all.
  • If user performs an action, I fetch the data, build models from it, do the magic object interaction, save it all back to data layer, then wrap it into presentation and serve.

How bad is such design?

Unfortunately I am not well-versed in software architecture/design terminology thus I might be failing to find the answer just because I don't know how to name things.

Edit: I don't mean to discard the Model part completely. I just mean that I will have Model sitting on Data and View sitting on Data too.

3 Answers 3


If you skip your business or domain layer the issue is that you will need to put your business logic somewhere, and it will likely end up in both your ui and data layer, which will make your application increasingly difficult to maintain. The other issue is that your ui and data layer will likely need to be replaced, such a when you want to move to wpf from winforms, or SQL to EF. So even though it might take a bit longer, create your business later up front, with proper unit tests.

  • There is business/domain/model part in it, just not between view and data.
    – aragaer
    Mar 24, 2014 at 1:51
  • While I agree with the need for separation, I've found that "what happens if you change UI frameworks or DB engines" is a bit if a red herring. Most projects never do, certainly aren't "likely need to be replaced", and any change will almost certainly require some coding work due to leaky abstractions anyway. Mar 24, 2014 at 8:27
  • @AvnerShahar-Kashtan I've already done that several times. Not DB engine, but data access technology, such as going from using Ado.Net directly to Entity Framework. I've also experienced moving from WinForms to Wpf, Asp.Net WebForms to MVC, and now MVC to WebApi. And you're right; if there are leaky abstractions its more difficult, which is why its important to not have leaks (and that can be done as well).
    – Andy
    Mar 24, 2014 at 12:12
  • @aragaer So what then is your business layer doing? The problem is the same though; you'll want to change your data structure at some point, and you'll immediately break every view. With the business layer in between, you'll have far fewer places to change.
    – Andy
    Mar 24, 2014 at 12:14
  • @Andy Business layer modifies data using some hidden variables not visible to user. Data structure is hidden inside data layer.
    – aragaer
    Mar 24, 2014 at 12:21

Consider working for awhile with an MVC framework like ASP.NET MVC or Ruby on Rails.

In these frameworks, most of the architectural decisions are made for you by convention. So you will be building a simple application on well-trodden ground. After awhile, you will begin to realize that most of the architecture is really not all that difficult to comprehend, and essentially boils down to three simple principles:

  1. Organization,
  2. Decoupling, and
  3. Separation of Concerns.

In MVC, the View has only one function: to show something to the user. It is decoupled from the Model via objects called ViewModels, which take data from the Model and transform it into the "shape" needed by the View in order for the view to properly display it. The Controller and the routing engine collectively form a switchyard, shunting requests from the web browser to an appropriate method for execution.

The Model contains everything else; your data, and all of your business logic. You can complicate this all you like, but the most typical way is either to create a service layer or repository. One one side of the repository is your data layer, on the other side are your controllers.

After a little while longer, you begin to realize that MVC is really just a UI metaphor and some endpoints that marry your URLS with application functionality. Your model and service layer, if designed correctly, can live quite happily just as easily in a Winforms application or a mobile application, so it only has to be written once.

  • Is there anything similar in Python? I am using Tornado right now.
    – aragaer
    Mar 24, 2014 at 1:53
  • wiki.python.org/moin/WebFrameworks. Look for the ones that claim to be MVC, or have the words "model", "view" and "controller" in them, like web2py does. Mar 24, 2014 at 2:22
  • It seems that tornado has a "View" in form of templates/uimodules and "Controller" in form of handlers. Thus I have to implement the Model on my own.
    – aragaer
    Mar 24, 2014 at 12:23
  • @aragaer: You are always responsible for designing and implementing the model, although you can get help doing so from tools like Object Relational Mappers such as Entity Framework, and Service Platforms such ASP.NET and Node.JS. Mar 24, 2014 at 15:26

You should have a Model, which encapsulate your business logics, and maybe a Viewmodel, if the data you are presenting is very different from your Model. The point is, trying avoid any business logic in your view layer, and make it really a dummy one. This way, your app is easy to test (UI is notoriously hard to test).

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.