不知道这个设计是一个好主意还是一个非常愚蠢的主意……答案

【问题标题】：Don’t know enough to know if this design is a great idea or an incredibly dumb one …不知道这个设计是一个好主意还是一个非常愚蠢的主意……
【发布时间】：2010-12-04 16:48:05
【问题描述】：

使用 C#、asp.net 3.5、SqlServer 2005，

尝试将一些控制反转与 3 层架构结合到我当前的任务中。

不知道这是一个好主意还是一个非常愚蠢的主意：

我创建了一个用户界面层、一个业务层和一个数据层。

UI 收集 4 个值，News 是一个业务层类的实例（称为 c），并使用 4 个值对其进行初始化。

UI 然后调用业务层类的该实例的方法来保存数据。

业务层类方法创建tsql字符串如

String.Format(@"insert into table1 (col1, 'col2', 'col3', col4) values ({0}, {1}, {2}, {3}); select @@identity", c.one, c.date1, c.date2, c.four) ;

并将字符串传递给数据层中类的 int 方法。

数据层使用字符串作为 ExecuteScalar 的 CommandText，并将@@identity 返回给业务层。

我会使用相同概念的变体通过数据读取器检索数据。

数据量不会很大，也不会是大容量应用程序。

我过去这样做的方式是将ui中收集的4个值传递给数据层，通过业务层设置sqlparms，将值传递给存储过程等，将它们传递回业务层等

【问题讨论】：

标签： design-patterns architecture inversion-of-control n-tier-architecture

【解决方案1】：

如果它对您（和您的团队）有意义并且按预期工作，那么无论它是什么，它都是一种很好的设计模式。

软件的主要技术要求是降低复杂性。如果您正在做的事情降低了您和您的团队头脑中的复杂性，那就让范式见鬼去吧。

【讨论】：

@Jason：有时（如果不是总是）糟糕的设计对设计师来说是有意义的，并且会按照设计师的意图工作。
@musigenesis - 那么它们根本不是糟糕的设计，除非其他人必须尝试使用它们。

【解决方案2】：

不，我认为你的新方法比你以前的方法差很多。如果您不小心，使用String.Format 会使您容易受到 SQL 注入攻击。

如果您并没有真正在“业务逻辑”层中执行逻辑，我会删除它并让您的“数据层”调用存储过程。

【讨论】：

【解决方案3】：

天哪！想说的太多，不知从何说起。

首先，我真的不知道 IoC 适合这里，因为你 newing 左右上课。

接下来，您将强制您的 BL 层构造一条 SQL 语句，这是不应该的。更糟糕的是，您基本上是在连接字符串以获得 SQL 语句。这是一种可怕的、可怕的做法（参见SQL injection）。

现在，我并没有在您的 BL 中看到任何“业务逻辑”。而且你正在搞乱原始 ADO.NET，这在当今是一个巨大的禁忌（除非你正在优化性能）。查看NHibernate 或BLToolkit。

这是我推荐的。查看Service Layer 的全部内容并尝试充实系统中的“服务”。由于您目前还没有任何“业务逻辑”，因此我认为 IFooPersistenceService 是唯一的服务。

接下来，阅读MVP 和MVC。这将帮助您更好地构建您的 UI。

最后，这是我对整体控制流程的看法。

用户以某种形式输入多个值并单击“保存”。您的IView 引发Saved 事件，该事件由IPresenter 处理。然后它从IView 的属性中获取这些值，创建一个业务对象（或就此而言的对象图）来保存这些值，调用IFooPersistenceService（Foo 是一个对象的名称）将其保存到数据库。 IFooPersistenceService 调用您选择的任何 ORM 并将 @@SCOPE_IDENTITY 的值交还给 IPresenter。

一旦您开始拥有任何类型的逻辑，请在 IPresenter 和 IFooPersistenceService 之间添加一个额外的层来保存所述逻辑。

参见this（递归）。

【讨论】：

【解决方案4】：

我对 web 应用程序中一个好的设计的看法是，业务层是您以面向对象的方式对应用程序建模并定义业务规则的地方。业务层是应用程序的核心。在一个典型的 Web 应用程序中，您很多时候只是通过业务层传递数据，但它仍然在数据和 ui 之间创建了一个很好的分离，而且无论如何它是非常容易编写和维护的代码，所以不要太担心如果这似乎是不必要的代码。

为了使您的业务层面向未来并易于测试，它不应该对它使用的任何外部服务有任何了解，它应该只定义服务应交付给您的应用程序的合同，因此您为您的服务（IDataStorage、IMailService、ILogger...）。这还允许您轻松交换服务实现，因为它们比您的核心业务模型更容易发生变化。

您可以将 DAL 视为一种服务，它允许您从持久存储中存储和检索数据，这可以是 xml 文件、Web 服务或更可能是数据库。通过这种方式，您的 DAL 是一种从您的持久存储中获取数据并将其转换为您的业务实体的服务。

当涉及到 UI 时，理想情况下，您应该以允许不同 UI（Webforms、mvc、silverlight）的方式创建业务层接口。如果您创建了一个好的应用程序，它将存在很多年，并且 UI 可能会更改很多次，并且会创建多个 UI。您的业务层不应该关心您将什么用作 UI 层，这样您就可以很好地分离各个层。

【讨论】：