Lew*_*ray 6 c# architecture winforms
我正在编写一个正在发展并变得非常广泛的Windows Forms应用程序.
最初我认为一个单独的图形组件项目,一个用于业务逻辑,一个用于数据访问,这是最好的方法.
随着应用程序变得越来越大,我开始认为更模块化的方法会更清晰......例如,包含用户控件,业务逻辑和每个"类别"数据的数据访问的项目.
例如......与产品相关的DAL对象以及单个项目中的关联业务对象和用户控件.这应该最终解决方案中的大量项目,每个项目都是自包含的.
然而,这可能会导致更多的复杂性,因为数据经常被链接(产品表与供应商表和订单表和零件清单表等相关联)因此,很难完全抽象每个类别.
在线有数百种软件架构文章,但并不是很多,它们可以帮助您将该架构转换为解决方案,项目和代码.
有人能指出我正确的方向吗？
我会将UI,数据和业务层保留在单独的项目中.这基本上减少了紧密耦合的可能性 - 例如,UI代码直接使用数据层等.现在,如果您希望将其垂直划分,那么您可以这样做,即产品将有三个项目UI,Business&Dal和等等.这里可以有多个注意事项:
就交叉类别参考而言,它们是无法避免的,但必须通过记录良好且设计合同来完成.例如,Orders UI可以调用Products BL来获取产品列表(请注意,许多其他UI组件将使用相同的方法来实现类似的功能).