6
我是否在这种体系结构上打破了面向对象的实践？
我有一个Web应用程序。我不认为这项技术很重要。该结构是一个N层应用程序，如左图所示。共3层。 UI（MVC模式），业务逻辑层（BLL）和数据访问层（DAL） 我的问题是我的BLL非常庞大，因为它具有通过应用程序事件调用的逻辑和路径。 通过应用程序的典型流程可能是： 在UI中触发的事件遍历BLL中的方法，执行逻辑（可能在BLL的多个部分中），最终执行DAL，返回到BLL（可能还有更多逻辑），然后向UI返回一些值。 此示例中的BLL非常繁忙，我正在考虑如何将其拆分。我也有自己不喜欢的逻辑和对象。 右边的版本是我的努力。 逻辑仍然是应用程序的UI和DAL之间的流动，但也有可能没有属性...只有方法（在这一层中的大多数类可能可能是静态的，因为他们不存储任何状态）。Poco层是存在具有属性的类的地方（例如Person类，其中会有名称，年龄，身高等）。这些与应用程序的流程无关，它们仅存储状态。 流可以是： 甚至从UI触发，并将一些数据传递到UI层控制器（MVC）。这将转换原始数据并将其转换为poco模型。然后将poco模型传递到逻辑层（即BLL），最后传递到命令查询层，可能会在途中被操纵。Command查询层将POCO转换为数据库对象（几乎是同一件事，但是一个是为持久性而设计的，另一个是为前端设计的）。存储该项目，并将数据库对象返回到“命令查询”层。然后将其转换为POCO，在其中返回到逻辑层，可能进行进一步处理，然后最终返回到UI 共享逻辑和接口是我们可能拥有持久数据的地方，例如MaxNumberOf_X和TotalAllowed_X以及所有接口。 共享逻辑/接口和DAL都是体系结构的“基础”。这些人对外界一无所知。 除了共享的逻辑/接口和DAL，其他一切都与poco有关。 流程仍然与第一个示例非常相似，但是它使每一层都对一件事情负责（无论是状态，流程还是其他）……但是我是否用这种方法打破了OOP？ 演示Logic和Poco的示例可能是： public class LogicClass { private ICommandQueryObject cmdQuery; public PocoA Method1(PocoB pocoB) { return cmdQuery.Save(pocoB); } /*This has no state objects, only ways to communicate with other layers such as the cmdQuery. Everything else is just …