Page 1 of 1
N-Tier Web Application?
Posted: Fri Jan 26, 2007 11:08 am
by montecristo
Hi Guys,
Just wondering if anyone knows of a good tutorial (php or Java) that shows how to build a web application.
I want to know how you seperate the business logic from the presentation, and the business logic from the Data access layer.
Any ideas on this would be much appreciated.
Thanks in advance
Posted: Fri Jan 26, 2007 11:21 am
by Kieran Huggins
"Model, View, Controller" design pattern is a good one for web apps.. popular too. Just google "MVC php web application" and I'm sure you'll find zillions of articles
Re: N-Tier Web Application?
Posted: Fri Jan 26, 2007 11:51 am
by Christopher
montecristo wrote:I want to know how you separate the business logic from the presentation, and the business logic from the Data access layer.
I am not sure that there is a good tutorial for that. The problem is that there are three key things that you need to be able to do:
1. Be able to identify whether code should be in the presentation layer, domain (business) layer or data access layer.
2. Have the discipline to maintain the dependencies so that lower layers have no dependencies on higher layers.
3. Have the wisdom to know when you can bend the rules, because strict separation and dependencies does not always make sense
I think Eric Evans'
Domain Driven Design and Fowler's
PoEAA are two books you may want to read, but there are many others. Start coding something that you actually need to get to work. The only way to grok these ideas is to actually come across a need to use them.
Posted: Mon Jan 29, 2007 8:50 am
by obiron
I prefer MVC-P
With web applications you can further separate content into content and presentation. All presentation should be done using CSS. Strictly speaking this also means that you should generate your content (especially tablular information) as XML so that the XSL and browser can decide whether display should be using tables or containers.
Having said that, I don't personally user XML but decide in the C layer whether to use DIV or TABLE and then use CSS to apply style the table rows and cells.
Try Code Igniter for an introduction to MVC, it does a good job, is fast and runs on PHP4 and 5
Posted: Tue Jan 30, 2007 10:18 am
by raghavan20
i have written briefly about it in my
blog
Posted: Tue Jan 30, 2007 2:24 pm
by Kieran Huggins
Model = data handling and access
View = the output (only in xhtml do you have a separate 'style' layer)
Controller = business logic, i.e. deciding what output to send, making stuff happen
Posted: Tue Jan 30, 2007 9:48 pm
by Christopher
Kieran Huggins wrote:Model = data handling and access
View = the output (only in xhtml do you have a separate 'style' layer)
Controller = business logic, i.e. deciding what output to send, making stuff happen
I believe that "business logic" goes in the Model. I think it is:
Model = domain/business logic
View = presentation logic
Controller = program flow logic
Posted: Tue Jan 30, 2007 11:07 pm
by Kieran Huggins
Believe arborint before me, it's quite possible I'm misusing the term - I'm shooting from the hip

Posted: Wed Jan 31, 2007 3:32 am
by raghavan20
arborint wrote:Kieran Huggins wrote:Model = data handling and access
View = the output (only in xhtml do you have a separate 'style' layer)
Controller = business logic, i.e. deciding what output to send, making stuff happen
I believe that "business logic" goes in the Model. I think it is:
Model = domain/business logic
View = presentation logic
Controller = program flow logic
I do not really think that business logic would go in model. Model should be used for R-O mapping or just act as data access layer.
domain logic if not implemented by controllers, it can form as a separate layer between Controller and Model layers.
your views are welcome. please give us examples how do you base the theory that business logic is implemented in Model. but for the fact, we can put business logic in Model or Controller, it will work anyway but we should know the best place through discussion.
Posted: Wed Jan 31, 2007 5:51 am
by sike
i am with aborint on this. i strongly believe that business logic belongs to the model and not to the controller. and by model i am not talking about data access. a model is conceptually ignorant of the data access (at least in my book).
cheers
Posted: Wed Jan 31, 2007 6:07 am
by raghavan20
sike wrote:i am with aborint on this. i strongly believe that business logic belongs to the model and not to the controller. and by model i am not talking about data access. a model is conceptually ignorant of the data access (at least in my book).
cheers
which book is it?
Posted: Wed Jan 31, 2007 6:15 am
by Ollie Saunders
If you put business logic in the model you can call on it in the controllers, you can reuse bits of model where and when you like. If you put it in the controller you hard code it there, there's no flexibly. Aborint has it right I'd say.
Basically I put anything that could possibly be used in more than one controller action in the model.
Posted: Wed Jan 31, 2007 5:34 pm
by Christopher
raghavan20 wrote:I do not really think that business logic would go in model. Model should be used for R-O mapping or just act as data access layer.
domain logic if not implemented by controllers, it can form as a separate layer between Controller and Model layers.
your views are welcome. please give us examples how do you base the theory that business logic is implemented in Model. but for the fact, we can put business logic in Model or Controller, it will work anyway but we should know the best place through discussion.
One of the less understood things about MVC is that it is
three things in
two layers. Where the separations are it probably the biggest confusion with MVC. It is my belief/understanding that the separations are more important than how you organize your code within each part.
And because of the "three things in two layers" structure there are conceptually only two separations. The first and most important is the separation between the Domain layer (Model) and the Presentation layer (View + Controller). That separation is probably the most important in programming -- not just MVC. The goal is to minimize/eliminate any dependencies by the Domain layer on the Presentation. This is an essential part of creating application tiers. Likewise the layer below the Domain is the Data Access layer (e.g. DB connections, files system, sockets, request, session, etc.) which in turn should not have dependencies on the Domain layer.
The second separation is between the View and Controller. I have never heard anyone say that you should definitively draw the line between those two in any specific spot. I described them above as "presentation logic" and "program flow logic" which gives you a general idea, but everyone defines where one ends and the other begins differently. I draw the line in different places in different applications and even in different modules within applications. I honestly don't think it matters as long as you are consistent and it works. And you can certainly combine View and Controller when needed. The simplest case of that is a content only page where your Action Controller just loads and displays a template.
A problem with MVC is that it is crystal clear and very malleable if you have a good understanding of and experience with these layers and dependencies. If you don't it's clear as mud.
Posted: Thu Feb 01, 2007 2:43 am
by raghavan20
are you claiming that data access layer does not fall under any of the MVC components and domain layer and domain logic alone forms the model component in MVC?