3 层架构分层和术语混搭
我对表达 3 层架构的不同可能性感到困惑。
Data-Access-Layer
Business-Layer
Presentation Layer (User Interface)
或者
Database (aka Backend)
Business-Layer
Presentation Layer (User Interface)
为什么你可以在第一种方法中跳过数据库？两者都使用数据库！ 数据库到底属于不属于分层？！
什么是错的，什么是对的？
你们有人能澄清一下吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
数据访问层不一定是数据库。它可以是一个 XML 文件。它可以是 RSS 提要。它可以是外部应用程序。它可以是任何您喜欢的将数据输入到您的应用程序中的东西。
所以它确实是这样的：
其中
[Data-Source]是数据库、XML、RSS 等等...我更喜欢将数据源本身视为驱动程序，而不是层。这种方法的灵活性使您可以交换数据源，而无需触及应用程序的其余部分。因此，如果您一开始使用 XML 文件作为后端数据，然后想将其更改为数据库，则只需触及 DAL 层 - 应用程序的其余部分并不关心，只要它仍然获取相同格式的数据。
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:
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.
您是否考虑过您的 dal 可能不使用数据库而可以使用 xml 文件？
第一种方法是使用更抽象的概念，即 3 层。
每层的内容取决于各层的实现。 Yuo 可能会发现您在 GUI/DB/BizLogic“程序”之间混合了层，但在抽象中您仍然保留这些层。
考虑到上述情况，您可以编写连接到数据库的代码。这是 DAL 还是逻辑？
我认为 DAL 当您编写代码来访问数据时。
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.
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.
表示层
这是应用程序的最顶层。表示层显示与浏览商品、购买和购物车内容等服务相关的信息。它通过将结果输出到浏览器/客户端层以及网络中的所有其他层来与其他层进行通信。
应用层（业务逻辑/逻辑层/数据访问层/中间层）
逻辑层从表示层中抽出，作为其自己的层，它通过执行详细处理来控制应用程序的功能。
数据层
该层由数据库服务器组成。这里存储和检索信息。该层保持数据中立并独立于应用程序服务器或业务逻辑。为数据提供自己的层还可以提高可扩展性和性能。
请参阅以下内容了解更多详细信息：
http://en.wikipedia.org/wiki/Multitier_architecture
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
Microsoft 的模式和实践小组有一份出色的架构指南，其中介绍了此问题的所有变体。它稍微侧重于 .NET，但非常适用于任何环境。强烈推荐。
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.