我有一个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 function
calls to allow flow via the program */
public PocoA Method2(PocoB pocoB)
{
pocoB.UpdateState("world");
return Method1(pocoB);
}
}
public struct PocoX
{
public string DataA {get;set;}
public int DataB {get;set;}
public int DataC {get;set;}
/*This simply returns something that is part of this class.
Everything is self-contained to this class. It doesn't call
trying to directly communicate with databases etc*/
public int GetValue()
{
return DataB * DataC;
}
/*This simply sets something that is part of this class.
Everything is self-contained to this class.
It doesn't call trying to directly communicate with databases etc*/
public void UpdateState(string input)
{
DataA += input;
}
}