Question

我最近获得了一个代码库，它做了一些与我通常做的事情有点不同的事情。

主要区别在于它似乎将元素（例如下拉列表控件）传递到业务逻辑层（在这种情况下是一个单独的项目但仍在同一解决方案中），其中绑定到业务数据的地方。

我的自然方法是始终显示UI所需的信息并将其绑定到那里。

我很难将第一种技术与任何标准模式相匹配，但这可能与实际实现相比，而不是它正在做的事情。

以前有没有人遇到过这种类型的架构？如果是这样，你能解释一下这些优势吗？

解决方案是ASP.Net网站。感谢。

谢谢，

Answer 1

我认为这是一个糟糕的架构，因为原始开发人员将业务逻辑紧密耦合到表示层。如果你想从webforms切换到MVC，你必须重构业务层的块，这不应该是这种情况！

如果可能的话，你应该考虑不再以这种方式开发网站。在此期间，您至少可以通过进一步分离逻辑来启动去耦过程。例如，如果您使用BindDropDown(DropDownList ddl)方法，请将方法拆分，以便使用GetDropDownData()方法返回实际业务对象，并BindDropDown 仅设置DropDownList的值。这样，至少，您将更容易摆脱表示层和业务层的紧密耦合。

当然，如果网站已经设计得那样（在表示层，中间“表示绑定”层和业务层之间有明确的界限），我可以看到一个案例，它是可以接受的。然而，听起来并非如此。

Answer 2

不，您应不将UI元素传递给域模型以进行绑定/填充。

理想情况下，您的域模型应该能够与您命名的Windows窗体/ WPF / Silverlight / ASP.NET / MVC一起使用。

现在，我有点理解你的业务对象应该知道如何存储和呈现自己等等，这是OO圣杯，但实际上这并不好用，因为通常存在依赖关系（数据库中间件，UI组件）等等你在BO组装中不想要的那些功能，严重限制了你的可重用性。

你可以做的事情会让你的用户觉得你的BO知道如何渲染自己就是使用扩展类（在一个单独的程序集中，包含依赖项）......就像...

public static class AddressUIExtensions
{
  public static void DisplayAddress(this Address add, AddressControl control)
  {
     ...
  }
}

然后API用户可以简单地执行

var ctrl = new AddressControl();
address.DisplayAddress(ctrl);

但你仍然有物理上的分离。

Answer 3

以前有没有人遇到过这种类型的架构？如果是这样，你能解释一下这些优势吗？

唯一的优势是发展速度 - 在短期内;所以它非常适合简单的应用程序，概念验证（PoC）等。

实现适当的抽象通常需要时间并带来复杂性。大部分时间都是你真正想要的，但有时一个应用程序可能被构建为一个简单的丢弃PoC。

在这种情况下，没有那么多的人坐下来讨论架构几个小时，并且决定在BL中绑定是有意义的 - 它通常是“无论如何 - 得到它” - 最快的“开发人员基于速度的呼叫。

当然，这种简单的懒惰或无知可能是其在其他情况下使用的原因。

Answer 4

您的业务层应返回一个模型 - 视图模型，UI层将依次用于填充所需的内容 - 句点。在ui组件 - 期间，应该没有任何内容发送到业务层。这很简单，而且规则很难和快。

是否应将UI组件传递给业务逻辑程序集以进行绑定

4 个答案: