我想大多数开发人员都对多层架构有所了解。我们有DAL（数据访问层），我们有BLL（业务逻辑层），并且在我们拥有UI的路的尽头。如果你有一个以某种方式遵循这些原则的项目，你是否保持（或者至少尝试）将这些东西保存/放置在它们概念所属的地方？我对与大多数其他人一起工作的大公司应用程序特别感兴趣。显然，你可以用你的私人玩具项目做任何你想做的事情，发明任何一种建筑并坚持下去。对于那些很多人为软件或整体混乱做出贡献的大项目来说，这并不容易。
例如，我碰巧看到UI组件直接进入数据库以获取BL不提供的一些“缺失”额外数据，UI和BL都使用低级元素（如表格字段），在我看来他们应该将这些操作委托给较低级别即DAL。特别伤心的是，在与高级开发人员讨论事情后，我发现他根本没有看到这个问题。
我们当然可以假设我和谁分享我的观点只是完美主义者，但我清楚地看到了一个非常不利的结果，因为我在一些任务中花费了很长时间来追踪所有“平行”数据传输到数据库和从数据库传输的路由，以及识别我实现的新功能现在可能受影响的人和方式。我认为，当有人决定快速破解并尽快完成任务时，这些进一步增加了开发/维护成本，增加了一些成本。
你的项目是“纯粹的”还是他们放弃了很久以前在层之间保持清晰界限的想法？如果你仍然保持正确，你如何处理那些不理解这些事情或不关心他们的同事，只是建立“定制”解决方案和黑客攻击？或者在某些时候你停止与风车战斗并接受它作为你的惩罚？ 编辑：有点惊讶，没有多少人对这个问题感兴趣。这是最不关心的标志吗？
答案 0 :(得分：19)
我们的应用程序越复杂，关注点就越重要。
在100 klocs，应用程序是一个大blob，表单类中的业务代码与其他任何地方一样多，并从业务类调用表单方法。由于大量的哭泣和咬牙切齿，我们将业务逻辑从显示逻辑中分离出来。任何需要通知用户其进度的类都会引发一个被UI沉没的事件。而且，有一段时间，一切都与世界是对的。
大约200 klocs，我们添加了一个数据层。我们的应用程序的体系结构使得我们的大多数数据在进入后立即被处理并立即丢弃。大多数配置信息都存储在与我们共享共生关系的第三方应用程序中。但是，设置开始在各种奇怪的角落积累。我们结束了三个配置管理系统，这些系统都错综复杂地融入了业务逻辑。通过广泛的重写，我们能够将配置信息分离到自己的层中，并将流数据处理到另一层。
在250千克线附近，我们决定终止与第三方供应商的关系，并使我们的应用程序独立。我们开始大规模重写，并且第一次在我们的应用程序中添加了一个实际的数据库。因为我们在流信息，数据存储和业务逻辑之间有明确的界限，所以这是一个相当无缝的集成。
现在，接近500 klocs，我们正在将应用程序转移到基于网格的架构。 UI不仅会与另一台计算机上的业务逻辑分离，而且应用程序发出的报价和订单的实际计算将进行负载平衡并展开以最大限度地提高效率。没有n层架构，这是不可能的。
在每个成长阶段，我们要么得到了清洁的分离，要么受到我们自己的沟通，数据，业务和用户界面的阻碍。在创建此应用程序时，可能没有比分离更重要的问题。
答案 1 :(得分：6)
这是一个很好的问题！每个ASP.Net开发人员都需要考虑的事情。你可能会得到很多答案，我会鼓励这些基本的常识性思想。
- 将交付的简单性和速度视为“成功”架构的一部分，而不仅仅是“纯度”。尝试在保持建筑理想和实践之间取得平衡。
- 一般来说，如你所说，将代码划分为多个层次似乎是有意义的。我建议虽然对于特定于页面的逻辑，如果它更简单/更快，它可以留在页面中 - 为什么为在一个地方使用的代码创建通用业务对象。正如人们所说的那样“过早优化是所有邪恶的根源。”。
- 将层和复杂性降至最低，以减少编码时间并提高可读性和可维护性。
这个网站上有很多纯粹主义者喜欢为建筑的网站做架构 - 使用架构作为工具来解决业务问题，而不仅仅是为了它本身的艺术形式，让它成为一个有用的工具，而不是它使用你。
答案 2 :(得分：2)
保持关注的分离。这非常重要。不要将UI与Biz和Biz混合使用数据层。使用抽象。使用抽象还可以使测试（单元测试）更容易（模拟它们）。我严格保持每一层都属于它。请记住，任何项目的最高成本都是它的维护。如果你把担忧混在一起，那么维持将成为一场噩梦。
答案 3 :(得分：2)
我们有一个Winforms应用程序和一个ASP.NET应用程序。它们都使用相同的Business Objects项目（大约140个类）。
Winforms项目包含大约350个表单和用户控件类，其中极少数（<10）需要从数据库中获取有关自己的元数据。
ASP.NET项目有大约100个.aspx页面。
我们有一个由5个类组成的数据访问层，它们与ADO.NET，线程和事务有关。它们将Business Objects的请求转换为SQL Server调用。
UI层（除少数需要有关表单大小调整的元数据的类外）根本不进行数据库访问。即便是少数例外情况也会像其他任何事情一样通过DAL。
业务层对数据访问层的内部工作一无所知，当它需要数据时，只调用DAL类上的公共方法。
当涉及到这种事情时，我根本不是原教旨主义者，但我们从来不需要在这个问题上偷工减料。
所以简而言之，100％纯净。它总是能够更好地做到正确。
我们现在必须有一个很好的理由离开这个。
答案 4 :(得分：1)
代码猴子和纯粹主义者与生活中的任何其他极端分子都很相似。
我们有极右翼和极左翼。很少有人正是其中之一，他们在他们坐的地方找到了良好的中间地带。如果不是极端主义者，我们就不知道边界在哪里。
就我的编码方式而言。我听纯粹主义者这样做的方式。我看到代码猴子正在研究他们的方法。我利用自己的经验选择了一个中间立场，它给了我适当的灵活性和可管理性，以及我需要的时间以及我实际上将要获得的金额。
答案 5 :(得分：1)
代码越大，生命周期越长，人们对代码的处理越多（同时或在生命周期内），她在层中的分离越重要。一开始，这似乎是一项不必要的工作，但从长远来看，它会多次付出代价。
至于强制分离：这就是为什么你的首席程序员或技术架构师需要良好的软技能和纯技术技能。您可以尝试在技术上强制执行分离（请参阅下文），但最后，您需要说服（或胁迫）您的开发人员以保持整体清晰。
但这并不是说强制执行分离的技术手段没有用处。事实上，我发现确保“跨境电话”有点难以实现，这会让人们花更多时间思考他们在跨境界面中真正需要的东西，从而带来更清晰的界面。如果难度是技术性的（因为你必须使用COM或CORBA）或其他东西（你必须一式三份地填写7页表格）并不重要。