20

我想大多数开发人员都有多层架构的想法。我们有 DAL（数据访问层），我们有 BLL（业务逻辑层），并且在接近尽头的地方我们有我们的 UI。如果您的项目以某种方式遵循这些原则，您是否保留（或至少尝试）保留/放置它们在概念上属于的地方？我对与许多其他人一起工作的大公司应用程序特别感兴趣。显然，你可以用你的私人玩具项目做任何你想做的事，发明任何类型的架构并坚持下去。对于有很多人为软件做出贡献或整体混乱的大型项目来说，这并不容易。

例如，我碰巧看到诸如 UI 组件直接进入数据库以获取一些 BL 不提供的“丢失”额外数据，UI 和 BL 都使用表字段等低级元素，我认为它们应该委托这些操作到较低级别即 DAL。在与高级开发人员讨论这些事情后，我看到他根本没有看到这有问题，这尤其令人难过。

我们当然可以假设我和任何与我观点相同的人都只是完美主义者，但我清楚地看到了一个非常不利的后果，因为我在一些任务中花了很长时间来追踪所有“平行”路线数据往返于数据库，并确定现在可能受到我实施的新功能影响的人以及以何种方式受到影响。在我看来，当有人决定快速破解这些东西并尽快关闭任务时，这些增加了进一步的开发/维护成本，超过了一些节省。

你的项目是“纯粹的”还是他们很久以前就放弃了在层之间保持清晰界限的想法？如果您仍然保持正确，您将如何处理不了解这些事情或不关心他们只是构建“自定义”解决方案和黑客攻击的同事？或者在某个时间点你停止与风车战斗并接受它作为你的惩罚？

4

6 回答 6

19

我们的应用程序越复杂，关注点分离就越重要。

100 kloc 的应用程序是一个大块，表单类中的业务代码与其他任何地方一样多，并从业务类调用表单方法。我们咬牙切齿地把业务逻辑和展示逻辑分开了。任何需要通知用户其进度的类都会引发一个被 UI 处理的事件。而且，有一段时间，世界一切都很好。

大约 200 klocs，我们添加了一个数据层。我们的应用程序的架构是这样的，我们的大部分数据一进入就被处理并立即丢弃。大多数配置信息都存储在与我们共享共生关系的第三方应用程序中。但是，设置开始在各种奇怪的角落累积。我们最终构建了三个配置管理系统，它们都错综复杂地融入了业务逻辑。通过广泛的重写，我们能够将配置信息分离到它自己的层中，并将流数据的处理分离到另一个层中。

在 250 kloc 线附近，我们决定终止与第三方供应商的关系，并使我们的应用程序独立。我们开始了大规模的重写，并且第一次在我们的应用程序中添加了一个实际的数据库。因为我们在流信息、数据存储和业务逻辑之间有清晰的界限，所以这是一个相当无缝的集成。

现在，接近 500 kloc，我们正在将应用程序迁移到基于网格的架构。不仅 UI 将与不同计算机上的业务逻辑分离，应用程序发出的报价和订单的实际计算将被负载平衡并分散以最大限度地提高效率。如果没有 n 层架构，这将是不可能的。

在成长的每个阶段，我们要么受到清晰分离的帮助，要么受到我们自己混乱的沟通、数据、业务和 UI 的阻碍。可能没有比创建此应用程序时的分离更重要的问题了。

于 2009-02-10T17:59:08.000 回答
6

这是一个很好的问题！每个 ASP.Net 开发人员都需要考虑的事情。你可能会得到很多答案，我鼓励这些基本的常识性想法。

--将简单性和交付速度视为“成功”架构的一部分，而不仅仅是“纯度”。尝试在坚持建筑理想和实用之间取得平衡。

--一般来说，正如你提到的，将代码分成几层似乎是有意义的。我建议尽管对于特定于页面的逻辑，如果它更简单/更快，它可以留在页面中——为什么要为只在一个地方使用的代码创建通用业务对象。正如人们所说的“过早的优化是万恶之源。”。

-- 将层数和复杂性降至最低，以减少编码时间并提高可读性和可维护性。

这个网站上有很多纯粹主义者喜欢为架构的网站做架构——使用架构作为工具来为业务问题提供解决方案，而不仅仅是为了它本身的艺术形式，让它成为一个有用的工具而不是比它使用你。

于 2009-02-10T17:32:34.117 回答
2

把顾虑分开。这是非常非常重要的。不要将 UI 与 Biz 和 Biz 与数据层混合。使用抽象。使用抽象也使测试（单元测试）更容易（模拟它们）。我严格把每一层都放在它所属的地方。请记住，任何项目中最高的成本是它的维护。如果你把这些问题混为一谈，那么维护将成为一场噩梦。

于 2009-02-10T17:44:51.357 回答
2

我们有一个 Winforms 应用程序和一个 ASP.NET 应用程序。它们都使用相同的 Business Objects 项目（大约 140 个类）。

Winforms 项目由大约 350 个表单和用户控件类组成，其中极少数 (<10) 需要来自数据库的关于它们自己的元数据。

ASP.NET 项目有大约 100 个 .aspx 页。

我们有一个由 5 个类组成的数据访问层，它们与 ADO.NET、线程和事务有关。它们将来自业务对象的请求转换为 SQL Server 调用。

UI 层（除了少数需要关于表单大小的元数据的类）根本不访问数据库。即使是少数例外也会像其他任何事情一样通过 DAL。

业务层对数据访问层的内部工作一无所知，当它需要数据时，只调用 DAL 类上的公共方法。

在这种事情上，我根本不是原教旨主义者，但我们从来不需要在这件事上偷工减料。

简而言之，100% 纯净。做对了总是会更好。

我们现在必须有充分的理由才能摆脱这种局面。

于 2009-02-10T17:51:32.557 回答
1

Code Monkeys 和 Purists 很像生活中的任何其他极端主义者。

我们有极右翼和极左翼。很少有人完全是其中之一，他们在他们坐的地方找到了一个很好的中间立场。如果不是因为极端分子，我们将不知道边界在哪里。

就我编码的方式而言。我听纯粹主义者的做法。我看到代码猴子正在讨论他们的方法。我利用我的经验来选择一个中间立场，它给我适当的灵活性和可管理性，以及我需要制作它的时间以及我实际将获得的资金数额。

于 2009-02-10T17:36:39.970 回答
1

代码越大，生命周期越长，不同的人在代码上工作的次数越多（同时或在生命周期中），分层就越重要。一开始，这似乎是一些不必要的工作，但从长远来看，它会为自己付出数倍的代价。

至于强制分离：这就是为什么你的首席程序员或技术架构师需要良好的软技能以及纯技术技能。您可以尝试从技术上强制分离（见下文），但最后，您需要说服（或强制）您的开发人员保持大局清晰。

但这并不是说强制分离的技术手段没有用。事实上，我发现确保“跨境调用”有些困难，这会让人们花更多时间思考他们在跨境界面中真正需要什么，从而使界面更加简洁。困难是技术上的（因为您必须使用 COM 或 CORBA）还是其他方面（您必须填写一式三份的 7 页表格）并不重要。

于 2009-02-10T19:45:13.797 回答