你们中有多少人进行三层设计？
多年来，三层设计一直是我数据库驱动应用程序的标准设计理念，它从未让我失望过。 对于那些练习它的人，描述一下你的层次。
我发现很多人混淆了业务层和数据访问层，使其更像是 2.5 层设计。
我更喜欢使用存储过程将数据层几乎完全移动到数据库中，并且在代码中只有一个非常轻量级的数据层，将存储过程调用包装到业务对象中。
你如何处理它？
编辑：如果您要做的只是定义什么是 3 层，请不要浪费时间回复。 我正在寻找特定的人如何实现它，您是否使用存储过程或 ORM，您如何处理 DAL 和 BLL 之间的循环依赖关系？ 之外，这个主题还有很多深度
- 除了UI
- 业务
- 数据
3-Tier design has been my standard design philosophy for years for database driven applications, and it has never failed me. For those who practice it, describe your layers.
I've found that many people muddle up the business tier and the data access tier, making it more like a 2.5-Tier design.
I prefer to move the data tier almost entirely into the database using stored procedures, and just have a very lightweight data tier in code that wraps sproc calls into business objects.
How do you approach it?
EDIT: If all you are going to do is define what 3-tier is, don't waste your time replying. I am looking for how specific people implemented it, did you use stored procedures or an ORM, how did you handle circular dependancies between the DAL and the BLL? Theres a lot of depth to this topic besides saying
- UI
- Business
- Data
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我主要开发 Web 应用程序已经有一段时间了，并且也一直遵循 3 层：
UI：纯 ASPX 页面。 实际上，有时很难将业务层从这里向下推，因为在这里进行快速计算或其他事情似乎很容易完成。 然而，我已经得到了足够的纪律，以确保页面后面的代码除了显示/隐藏面板、更新用户输入等之外什么也不做。
DAL：所有数据访问层的东西。 我非常喜欢使用可用的 XSD/DataTable/TableAdapter 类。 我还使用基于存储过程的 CRUD 方法，因此将适配器连接到存储过程很容易。
BLL：在我的大多数应用程序中，业务层往往是三层中最轻的，因为它们主要是 CRUD 类型的应用程序，并内置了一些报告。
I've been doing primarly web apps for a while now and have been following 3-Tier as well:
UI: Pure ASPX pages. It is actually kind of hard to push your business layer down from here at times because doing a quick calculation or something seems so easy to do here. However, I've gotten disciplined enough to make sure the code behind pages are doing nothing but showing/hiding panels, updating user input, etc.
DAL: All data access layer stuff. I have really enjoyed using the XSD/DataTable/TableAdapter classes that are available. I also use stored procedure based CRUD methods, so hooking up the adapters to the stored procs is easy.
BLL: The business layer tends to be the lightest of the three layers in most of my apps here, since they are primarily CRUD type apps with some reporting built in.
我实践 3 层设计的方式与您的做法大致相同，即我使用存储过程来处理大部分（如果不是全部）与数据库的通信。 我对课程的设计进行了设计，使每个课程都有特定的目的，以降低复杂性并在发生变化时提供更大的灵活性。
我在三层设计中遇到的最大问题之一是在哪里放置输入验证。 我经常发现自己在 UI 和业务层中重复验证，以便通过快速验证检查使用户受益，并确保进出数据层的数据有效。 您如何处理验证？
I practice 3-tier design much the same way you do in that I use stored procedures to handle most, if not all of my communication with the database. I approach the design of my classes so that each one has a specific purpose in order to reduce complexity and to allow for greater flexibility when it comes to change.
One of the biggest problems I come across in 3-tier design is where to put input validation. Often times I find myself duplicating validation in both the UI and business layer to benefit the user with quick validation checking and to ensure that the data going in and coming out of the data layer is valid. How do you handle validation?
第三层：
3-tier:
更多旁注：永远不要忘记 n 层分层是逻辑分层，而不是进程的物理分离。 即，不需要让业务逻辑与表示代码运行在不同的进程（或不同的盒子上）。 重要的是保持代码干净。
物理上分离表示代码和业务逻辑的宣传已经有一段时间了，例如，通过使用 Web 服务连接到后端。 在某些情况下，这是一个好主意，但无论如何都没有必要，但会使您的架构、部署、设计和性价比显着复杂化。
More of a side note: never forget that the n-tier layering is a logical layering, not a physical separation of processes. I.e., there should be no need to have the business logic running in a different process (or on a different box) than the presentational code. The important thing is the keeping the code clean.
Physically separating presentational code and business logic has been advertised for some time, e.g., by using webservices to connect to a backend. There are cases where this is a good idea, but it's not necessary in any way, but will significantly complicate your architecture, deployment, design, and cost performance.
n 层设计
我认为分层效果很好。 看看 OSI 模型中的各个层。我已经使用了您提到的三个层描述一下，这种方法确实很有帮助。 模型视图控制器的抽象在大型桌面应用程序中通常很有帮助。 你可以不断地将事情分成越来越小、更易于管理的部分。 存在一个收益递减点。 而且，有时我们想要删除抽象层，也许直接与硬件对话——这取决于应用程序的目标。
n-tier design
I think that layering works quite well. Take a look at the tiers in the OSI model. I've used the three tiers that you describe and that approach really helped. The abstraction of Model View Controller is often helpful in a large desktop application. You can keep splitting things down into smaller and smaller more manageable pieces. There is a point of diminishing returns. And, there are occasions when we want to remove the abstraction layers and perhaps talk directly to the hardware -- it depends on the goals of your application.
我发现 2.5 层设计最适合我创建的新 Web 应用程序。
我通常从 2 个类库和 1 个 Web 应用程序开始。
Company.Data（类库）Company.Web（类库）（包含PageBase、自定义控件、辅助函数等）Company.Web.WebApplication（Web 应用程序）对于我创建的应用程序，我仅使用存储过程来访问数据。
事实上，我已经创建了 CodeSmith 模板来生成所有存储过程、数据和业务类。
该程序集主要由实体数据类和集合组成。
例如，我的 Web 应用程序中通常有一个名为
Settings的表。将生成一个名为
Setting和SettingCollection的类。因此，如果我需要加载特定设置，我可以这样做......
或者创建一个新设置，我只是不在构造函数中传递值。
Company.Data程序集中的命名空间通常看起来像像这样..（这个命名空间用于创建自定义方法来访问数据）
我还根据主键、外键和唯一索引生成自定义方法。
例如，设置表中的名称列具有唯一索引。
将自动生成一个名为
GetSettingByName的共享方法，该方法将返回一个设置对象。此方法位于
Company.Data.BusinessObjects命名空间中对于实体和业务对象类，会生成两个文件。 1为每次生成，1为可编辑且仅生成
第一次。 我使用部分类来允许我添加自定义代码而不被覆盖。
对我来说，这种方法非常有效。 Codesmith 一代为我节省了无数的编码时间。 我可以向表中添加 5 个新列，然后重新生成
几秒钟内完成所有新代码。 存储过程将被删除并重新创建。
2.5 层设计效果很好，因为我的应用程序仅使用一个数据库，即 Sql Server。 以后需要使用access、oracle、mysql的情况就不会发生了。
I have found that the 2.5 Tier design to work best for the new web applications I have created.
I typically start off with 2 class libraries and 1 web application.
Company.Data(Class library)Company.Web(Class library) (ContainsPageBase, Custom Controls, Helper functions, etc)Company.Web.WebApplication(Web Application)For applications that I have created, I only use stored procedures to access the data.
In fact, I have created CodeSmith templates to generate all of the stored procedures, data and business classes.
This assembly consists mainly of the entity data classes and collections.
For example, I typically have a table called
Settingsin my web applications.A class called
SettingandSettingCollectionwill be generated.So if I need to load a specific setting, I can do this..
or to create a new setting, I just do not pass a value in the constructor
My namespaces in the
Company.Dataassembly typically look like this..( This namespace is used to create custom methods to access data)
I also generate custom methods based on primary keys, foreign keys, and unique indexes.
For example, the name column in the settings table has a unique index.
A shared method called
GetSettingByNamewill be generated automatically and this will return a setting object.This method would be in the
Company.Data.BusinessObjectsnamespaceFor the entity and business object classes, two files are generated. 1 that is generated each time and 1 that is editable and only generated
the first time. I use partial classes to allow me to add custom code with out it being overwritten.
For me, this methodolgy has worked really well. Codesmith generation saves me countless hours of coding. I can add 5 new columns to a table, regenerate
all of the new code in seconds. Stored procedures will be dropped and recreated.
The 2.5 tier design works well because my application is only going to use one database and that is Sql Server. The need to use access, oracle, mysql in the future wont happen.
我们使用大约 6 层设计。
浏览器端 Javascript 等等。 这是纯粹的视觉糖，几乎没有商业价值或加工价值。 这里的任何输入验证都是多余的检查——它们可以被绕过，所以我们不信任它们。
服务器端 HTML 演示。 这部分是业务规则驱动的。 但我们使用的模板语言没有进行任何处理。
服务器端视图功能、业务逻辑“控制”。 这是导航、验证和“更高级别”的面向应用程序的处理发生的地方。 这是状态改变发生的地方——计算、更新、删除等。这就是处理。 这是强制执行身份验证和授权的地方。
模型定义（使用 ORM 层）。 这就是对象模型。 它映射到关系模型。 它包括作为对象方法的所有模型级处理。 这是进行一些计算的地方，过滤、计数、排序都在这里定义。 这是我们有用的数据视图。
访问层（某种数据库连接）。 取决于数据库产品。 它由 ORM 层管理，因此我们不做任何编码，只需配置。
数据库中的持久存储（无存储过程，无触发器）。
We use about a 6 tier design.
Browser-side Javascript and what-not. This is pure visual sugar with little business value or processing. Any input validations here are redundant checks -- they can be bypassed, so we don't trust them.
Server-side HTML presentation. This is partially business-rule driven. But there's no processing in the template language we use.
Server-side view functions, business logic, "control". This is where navigation, validation and the "higher-level" application-oriented processing occurs. This where state-change occurs -- things are computed, updated, deleted, etc. This is the processing. This where authentication and authorization are enforced.
Model definitions (using an ORM layer). This is the object model. It maps to a relational model. It includes all of the model-level processing as object methods. This is where some calculations are done, filtering, counting, ordering, are defined here. This is our useful view of the data.
Access layer (some kind of database connectivity). Depends on the database product. It's managed by the ORM layer, so we don't do any coding, just configuring.
Persistent storage in the DB (no stored procedures, no triggers).
我们曾经使用以下方法来处理它：
- UI 层（所有 UI 所在的位置）
- 业务层（所有业务逻辑所在）
- 数据层（所有数据库访问都在其中）
We once approached it using the following:
- UI Layer (where all the UI is)
- Business layer (where all the business logic is)
- Data layer (where all the DB access is)