I suppose most of the developers have an idea of multi-layer architecture. We have DAL (Data access layer), we have BLL (business logic layer) and somewhere near the end of the road we have our UI. If you have a project which somehow follows these principles, do you keep (or at least try) to keep/put the things where they conceptually belong? I'm especially interested in big company applications where you work together with many other people. Clearly you can do whatever you want with your private toy project, invent any kind of an architecture and stick to it. It is not so easy with big projects where lots of people contributed to the software or overall mess.
例如,我碰巧看到UI组件直接进入数据库以获取BL不提供的一些"缺失"额外数据,UI和BL都使用低级元素(如表字段),我认为他们应该委托这些操作到了较低级别即DAL.特别令人伤心的是,在与高级开发人员讨论事情后,我发现他根本没有看到这个问题.
我们当然可以假设我和任何与我有共同观点的人都只是完美主义者,但我清楚地看到了一个非常不利的结果,因为我在一些任务中花了很长时间来追踪所有的"平行"路线.数据往返数据库并识别我实施的新功能现在可能受影响的人和方式.我看到它的方式,当有人决定快速破解这些东西并尽快完成任务时,这些会增加进一步的开发/维护成本.
你的项目是"纯粹的"还是他们放弃了很久以前在层之间保持清晰界限的想法？如果你仍然保持正确,你如何处理那些不理解这些事情或不关心他们的同事,只是建立"定制"解决方案和黑客攻击？或者在某些时候你停止与风车战斗并接受它作为你的惩罚？编辑:有点惊讶,没有多少人对这个问题感兴趣.这是最不关心的标志吗？
我们的应用程序越复杂,关注点的分离就越重要.
在100 klocs,应用程序是一个大blob,表单类中的业务代码与其他任何地方一样多,并从业务类调用表单方法.由于大量的哭泣和咬牙切齿,我们将业务逻辑从显示逻辑中分离出来.任何需要通知用户其进度的类都会引发一个被UI沉没的事件.而且,有一段时间,一切都与世界是对的.
大约200 klocs,我们添加了一个数据层.我们的应用程序的体系结构使得我们的大多数数据在进入后立即被处理并立即丢弃.大多数配置信息都存储在与我们共享共生关系的第三方应用程序中.但是,设置开始在各种奇怪的角落中积累.我们结束了三个配置管理系统,这些系统都错综复杂地融入了业务逻辑.通过广泛的重写,我们能够将配置信息分离到自己的层中,并将流数据处理到另一层.
接近250 kloc系列,我们决定终止与第三方供应商的关系,使我们的应用程序独立.我们开始大规模重写,并且第一次在我们的应用程序中添加了一个实际的数据库.因为我们在流信息,数据存储和业务逻辑之间有明确的界限,所以这是一个相当无缝的集成.
现在,接近500 klocs,我们正在将应用程序转移到基于网格的架构.UI不仅会与另一台计算机上的业务逻辑分离,而且应用程序发出的报价和订单的实际计算将进行负载平衡并展开以最大限度地提高效率.没有n层架构,这是不可能的.
在每个增长阶段,我们要么得到了清洁的分离,要么受到我们自己的沟通,数据,业务和用户界面的阻碍.在创建此应用程序时,可能没有比分离更重要的问题.
这是一个很好的问题!每个ASP.Net开发人员都需要考虑的事情.你可能会得到很多答案,我会鼓励这些基本的常识性思想.
- 作为"成功"架构的一部分,考虑简单性和交付速度,而不仅仅是"纯度".尝试在保持建筑理想和实践之间取得平衡.
- 一般来说,如你所说,将代码划分为多层似乎是有意义的.我建议虽然对于特定于页面的逻辑,如果它更简单/更快,它可以留在页面中 - 为什么为在一个地方使用的代码创建通用业务对象.正如人们所说的那样"过早优化是所有邪恶的根源."
- 将层和复杂性降至最低,以减少编码时间并提高可读性和可维护性.
这个网站上有许多纯粹主义者喜欢为建筑的网站做架构 - 使用架构作为工具来提供解决业务问题的工具,而不仅仅是为了它本身的艺术形式,让它成为一个有用的工具而不是而不是使用你.
京公网安备 11010802040832号 | 京ICP备19059560号-6 