我是否在这种体系结构上打破了面向对象的实践?
我有一个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 …