Hi!
I am confused about the different possibilities to express a 3-Tier architecture.
Data-Access-Layer
Business-Layer
Presentation Layer (User Interface)
or
Database (aka Backend)
Business-Layer
Presentation Layer (User Interface)
Why can you skip the database in the 1st approach? Both use a database! Does the database belong to the layering or not?!
What is wrong and what is right?
Can someone of you clarify this :)?
Thanks in advance!
Have you considered that your dal may not use a db it could use an xml file?
The first approach is using a more abstract concept which is what the 3 tier layer is.
The stuff that goes in each layer depends on the implementation the the tiers. Yuo may find that you mix your layers between GUI/DB/BizLogic 'programs' but in the abstract you still mantain those layers.
Data-Access-Layer
Business-Layer
Presentation Layer (User Interface)
Considering the above you may wirte code that connects to your db. Is that the DAL or the logic?
I'd consider that the DAL as you are writing to code to access the data.
Presentation tier
This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.
Application tier (Business Logic/Logic Tier/Data Access Tier/Middle Tier)
The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
Data tier
This tier consists of Database Servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
See following for more details:
http://en.wikipedia.org/wiki/Multitier_architecture
Data-Access-Layer
Business-Layer
Presentation Layer (User Interface)
Data-Access-Layer is not necessarily a database. It could be an XML file. It could be an RSS feed. It could be an external application. It could be anything you like that gets data into your application.
So it's really:
[Data-Source]
Data-Access-Layer
Business-Layer
Presentation Layer (User Interface)
where [Data-Source] is database, XML, RSS, whatever... I prefer to think of the data-source itself as a driver, not a layer.
The flexibility of this approach allows you to swap out your data source without touching the rest of the application. So if you began by using XML files as your back-end data, and then you want to change it to a database instead, you only touch the DAL layer - the rest of the application doesn't care as long as it still gets the data in the same format.
Microsoft's Patterns and Practices group has an excellent architecture guide that goes through all the variations on this issue. It's slightly focused towards .NET, but is very applicable to any environment. Highly recommended.