【问题标题】:Business Logic Layer业务逻辑层
【发布时间】:2010-12-18 01:34:43
【问题描述】:

我正在使用带有 Telerik 控件 (v2009 q2) 的 asp.net 对数据驱动的应用程序进行编程。 我有一个名为 BLL 的类,它包含(几乎只有)静态类,它们返回不同的对象,以一些 id 作为参数。通常以列表形式返回一组对象。

我的问题是,这是否存在任何架构缺陷,始终使用静态。我知道人们将他们的业务层和数据访问层作为不同的项目。它作为一个项目有什么好处?所以我可以添加更多功能,或者只是这样更整洁。

提前致谢

【问题讨论】:

    标签: asp.net business-logic-layer


    【解决方案1】:

    使用静态方法作为您的进入方法并不是一个特别大的问题。这实际上取决于您是否有需要存储状态的工作区域,因为静态定义可能不允许您存储或分离状态信息。幸运的是,从使用静态声明倒退到成员声明通常没有相反的痛苦。如果从此类方法返回的项目完全负责状态,您甚至可能不会遇到此问题。

    单独的库/项目对于划分工作单元很有用。没有严格要求所有内容都必须分离到不同的库中,尽管您可能会看到静态成员变量的怪癖,尤其是在多线程应用程序中,正如 Dave Swersky 所提到的那样。

    拥有单独的库还可以为您带来以下好处:

    1. 在开发过程中更好地分离变更,因为项目边界通常与源代码控制边界重合,从而允许更多人在整个平台表面上同时工作。
    2. 如果布局和界面兼容,则可以在生产中独立更新单独的部分。
    3. 更好地组织每一层给定细分的行为、特征和角色相交,无论是 BLL 还是 DAL。一些开发人员更喜欢根据允许用户对给定 BLL 中提供的项目进行操作的内容来严格隔离组件。

    但是,有些人发现大型单体库更适合他们。以下是在这种情况下很重要的一些好处。

    1. 对于旧组件和依赖项很少更改的项目(对于 C/C++ 开发人员尤其重要!),更快的编译时间。不会更改的源文件可以共同提示并允许编译器避免重新编译整个项目。
    2. 单个(或低数量)文件升级和管理,适用于需要尽量减少给定位置的对象数量的项目。这对于提供图书馆供其他方使用的人来说是非常可取的,因为人们不太容易受到个别项目被无序发布或更新的影响。
    3. Visual Studio .NET 项目中的自动命名空间布局,其中使用子文件夹会自动暗示为新代码添加而存在的初始命名空间。不是特别好的福利,但有些人觉得这很有用。
    4. 通过数据库或服务器抽象分离 BLL 和 DAL 组。这在某种程度上是中间立场,但作为一个组织级别,人们发现这个级别更适合长期发展。这使人们可以通过存储或接收事物的位置来识别事物。但是,作为权衡,单个项目可能会更复杂——尽管可以通过 #3 进行管理。

    最后,我注意到的一件事是,听起来您已经实现了嵌套的静态类。如果使用您的工作的其他人处于智能感知或其他环境快捷方式不可用的环境中,他们可能会发现此设置使用起来非常麻烦。您可能会考虑将某些级别的嵌套展开到单独的(或嵌套的)命名空间中。这也有利于减少声明感兴趣的项目所需的类型,因为命名空间声明只需要出现一次,而静态嵌套项目每次都需要出现。你的同行会喜欢这个的。

    【讨论】:

      【解决方案2】:

      将 BLL 和 DAL 放在单独的项目中(即单独的程序集)意味着它们可以与不同的用户界面一起使用而无需重新编译,但更重要的是 DLL 的边界接口和依赖关系定义得比较明确(尽管它不能保证一个伟大的设计,它至少强制分离)。仍然可以有一个逻辑分离度很高的单个程序集,因此它不是必需的,也不是足够的。

      就静态方法与业务对象类而言,这可能是不寻常的并且可能有缺点,但它不会真正影响您的层是否分离。

      【讨论】:

        【解决方案3】:

        如果您的应用程序是无状态的,那么全静态方法/类应该不是问题。但是,如果您的应用是多线程的,并且 BLL 确实读取并提交,您可能会遇到线程安全问题。

        【讨论】:

          【解决方案4】:

          单独项目的一个优点是,如果您需要更新应用程序但只更改 BLL,您可以进行更改,重新编译 DLL 并将其放入应用程序在 IIS 中部署的 bin 文件夹中,而无需重新部署整个 Web 应用程序

          【讨论】:

            【解决方案5】:

            我的问题是有没有 对此的架构缺陷,总是 使用静态。

            这种方法的一个缺陷是您不能将接口应用于静态方法。一种可能的解决方法是使用单例模式,但您需要注意线程问题。

            我知道人们制作他们的业务层 和 DataAccess 层不同 项目。它有什么好处 作为一个项目?所以我可以添加更多 功能或只是它更整洁 那样。

            优点:

            1. 让多个开发人员更容易开展工作(取决于您的环境和源代码控制)
            2. 将逻辑/保护级别与解决方案的其余部分强制分离
            3. 如果您的 BLL 变大,则更易于分组和管理

            【讨论】:

              【解决方案6】:
              namespace BLL
              {
                  public class tblCity
                  {
                      public tblCity()
                      {
                          //
                          // TODO: Add constructor logic here
                          //
                      }
                      private int iCityId;
                      private string sCityName;
              
                      public int CityId
                      {
                          get
                          { return iCityId; }
                          set
                          { iCityId = value; }
                      }
                      public string CityName
                      {
                          get
                          {
                              return sCityName;
                          }
                          set
                          { sCityName = value; }
              
                      }
                      public int InserttblCity()
                      {
                          DBAccess db = new DBAccess();
                          //db.AddParameter("@iSid", iSid);
                          db.AddParameter("@sCityName", sCityName);
              
                          return db.ExecuteNonQuery("tblCity_Insert", true);
                      }
                      public DataSet SelectAlltblCity()
                      {
                          DBAccess db = new DBAccess();
                          return db.ExecuteDataSet("tblCity_SelectAll");
                      }
                      public DataSet CheckCityName()
                      {
                          DBAccess db = new DBAccess();
                          db.AddParameter("@sCityName", sCityName);
                          return db.ExecuteDataSet("tblCity_CheckCity");
                      }
                      public DataSet SelectDistinctCityWithId()
                      {
                          DBAccess db = new DBAccess();
                          //db.AddParameter("@iCityName", iCityName);
                          return db.ExecuteDataSet("tblCity_getLastId");
                      }
                      public int UpdatetblCity()
                      {
                          DBAccess db = new DBAccess();
                          db.AddParameter("@iCityId", iCityId);
                          db.AddParameter("@sCityName", sCityName);
                          return db.ExecuteNonQuery("[tblCity_Update]", true);
                      }
                      public int DeletetbltblCity()
                      {
                          DBAccess db = new DBAccess();
                          db.AddParameter("@iCityId", iCityId);
              
                          return db.ExecuteNonQuery("[tblCity_Delete]", true);
                      }
                      public DataSet FindPropertyLocationSubCategory()
                      {
                          DBAccess db = new DBAccess();
                          db.AddParameter("@iCityId", iCityId);
                          return db.ExecuteDataSet("tblPropertyDetails_FindPropertyLocationSubCategory");
                      }
                      public DataSet SelectDistinctPLCNAmeWithId()
                      {
                          DBAccess db = new DBAccess();
              
                          return db.ExecuteDataSet("tblCity_getLastId");
                      }
              
                  }
              }
              

              【讨论】:

              • 这个问题似乎需要更多的文字答案而不仅仅是代码。你能补充一些解释吗?
              猜你喜欢
              • 2011-12-03
              • 2011-11-26
              • 2017-04-29
              • 2016-08-12
              • 2014-09-04
              • 2013-02-18
              • 1970-01-01
              • 2017-08-08
              • 1970-01-01
              相关资源
              最近更新 更多