N-Tier Web Application?
Moderator: General Moderators
-
montecristo
- Forum Newbie
- Posts: 20
- Joined: Thu Oct 19, 2006 9:51 am
N-Tier Web Application?
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
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
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: N-Tier Web Application?
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:montecristo wrote:I want to know how you separate the business logic from the presentation, and the business logic from the Data access layer.
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.
(#10850)
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
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
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
i have written briefly about it in my blog
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I believe that "business logic" goes in the Model. I think it is: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
Model = domain/business logic
View = presentation logic
Controller = program flow logic
(#10850)
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
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.arborint wrote:I believe that "business logic" goes in the Model. I think it is: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
Model = domain/business logic
View = presentation logic
Controller = program flow logic
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.
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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.
Basically I put anything that could possibly be used in more than one controller action in the model.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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.
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.
(#10850)
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact: