三层架构的好处？
我并不完全相信三层架构的好处。那么，为什么会出现 LINQ 这种更轻量级的数据访问方法呢？任何意见将不胜感激。
I'm not entirely convinced of the benefits of a 3-tier architecture. Why, then, has LINQ emerged, which is a lighter data access approach? Any input would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
n 层应用程序的主要好处之一（当然还有比我在这里提到的更多的好处）是它带来的关注点分离。如果您构建应用程序，即数据访问的责任由数据访问层负责（
LINQ2SQL就是一个很好的例子），验证和其他业务逻辑位于一个或多个其他层中、演示文稿等，您可以更改任一层中的详细信息，甚至替换任一层，而无需重新编写应用程序的其余部分。另一方面，如果您选择不实现 n 层方法，您很快就会注意到，例如更改单个数据库表的名称将需要您遍历整个应用程序- 每一行代码 - 搜索需要更新的 SQL 语句。在 n 层应用程序中（如果您已正确完成操作），您只需在代码中更改表名称一次。
One of the main benefits of n-tier applications (there are of course many more than what I mention here) is the separation of concerns that it brings. If you structure your application so, that the responsibility for i.e. data access is held in a data access layer (
LINQ2SQLis a perfectly good example of one), validation and other business logic in one or more other layers, presentation in yet another one etc., you can change details in, or even replace, an either layer without having to re-write the rest of your applicaton.If, on the other hand, you choose not to implement an n-tier approach, you'll quickly notice that for example changing the name of one single database table will require you to go through your entire application - every single line of code - in search for SQL statements that need to be updated. In an n-tier application (if you've done things rigth), you'll only have to change the table name once in your code.
在你意识到这些框架和模式解决的问题之前，你需要以天真的方式去做并失败。
很多事情都发生在我身上。 SVN 分支看起来像是一种杂乱无章的做事方式，直到有一天我希望我在最后 5 次提交之前就已经分支了。 C++ 模板看起来毫无用处且令人困惑，直到我恍然大悟；现在我经常使用它们。每一个 J2EE 功能对于任何人来说都看起来像是无用的臃肿，直到您真正构建了一个足够大的应用程序并且出现了问题；那么它们可能正是您所需要的。 （因此“要求”你使用它们是一个缺陷）
You need to do it the naive way and fail before you realize the problems those frameworks and patterns solve.
Happened to me with many things. SVN branches looked like a disorganized way to do things, until one day I wished I had branched before my last 5 commits. C++ templates seemed useless and confusing, until I got enlightened; now I use them pretty often. And every single J2EE feature will look like useless bloat to anyone, until you actually build an app big enough and have problems; then they may be exactly what you need. (thus it's a flaw to "require" you use them)
与大多数工程领域一样，永远不存在完美的一刀切的开发或架构解决方案。 n 层架构也是如此。
例如，相当多的应用程序可以在一层或两层架构中完美运行。例如，Microsoft Word 作为单层系统就表现得非常好，谢谢。
大多数业务应用程序已经开始使用层（与层不同：层是虚拟的，层是物理的），因为它使得在一个地方拥有表示逻辑、在另一个地方拥有业务逻辑和持久性逻辑变得更加容易其他地方。根据应用程序的不同，拥有更多层也是有意义的：我最近完成了一个项目，在 UI 客户端和 SQL 数据库之间有大约 16 层。 （我们有 REST 服务、协调层、混合数据库，凡是你能想到的。都是为了应对相当大的部署挑战而设计的。）
所有这些层的好处是
LINQ（语言集成查询）也确实有帮助，因为可以抽象出使用持久层的许多更困难的部分。例如，
。如果没有 LINQ，开发持久层总是重复的，从来都不是一件好事。
Like in most fields of engineering there's never a perfect one-size-fits-all solution for development or architecture. So it is with n-tier architectures.
For example, quite a few applications run perfectly well as a one-tier or two-tier architecture. Microsoft Word, for example, does quite well, thank you, as a single-tier system.
Most business applications have started using layers (as distinct from tiers: layers are virtual, tiers are physical) as it makes life much easier to have presentation logic in one place, business logic in another, and persistence logic somewhere else. It can make sense too depending on the application to have lots more layers: I recently finished up a project with about sixteen layers between the UI client and the SQL database. (We had REST services, co-ordination layers, mixed databases, you name it. Made for quite a deployment challenge.)
The nice thing about all these layers are
LINQ, the Language Integrated Query, really helps too, as can abstracts away much of the harder parts of working with persistence layers. For instance
Without LINQ developing persistence layers was invariably repetitive, never a good thing.