Building presentation layer directly on data layer

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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