asp.net - 业务逻辑层

Question

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

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

提前致谢

Answer 1

Using static methods as your method of entry is not a particularly big concern. It really depends on whether you have areas of work where you need to store state, as static definitions may not allow you to store or separate state information. Fortunately, going backward from having used static declarations to member declarations is usually less painful than the reverse. You might not even encounter this as an issue if the items returned from such methods are solely responsible for state.

Separate libraries/projects are useful for partitioning units of work. There are no strict requirements that everything must be separated into different libraries, although you may see quirks with static member variables, particularly in multi-threaded apps, as mentioned by Dave Swersky.

Having separate libraries also gives you the following benefits:

1. Better separation of changes during development, as project boundaries usually coincide with source-control boundaries, allowing more people to work concurrently over the entire surface of your platform.
2. Separate parts that may be updated independently in production, provided layout and interfaces are compatible.
3. Better organization of what behaviors, features, and roles intersect for a given segment at each layer, whether BLL or DAL. Some developers prefer to strictly isolate components based on what users are allowed to operate on items provided in a given BLL.

However, some parties have found that large monolithic libraries work better for them. Here are some benefits that are important in this scenario.

1. Faster compile times for projects where older components and dependencies rarely change (especially important for C/C++ devs!). Source files that don't change, collectively, can hint and allow the compiler to avoid recompiling whole projects.
2. Single (or low-count) file upgrades and management, for projects where it is important to minimize the amount of objects present at a given location. This is highly desirable for people who provide libraries for consumption by other parties, as one is less susceptible to individual items being published or updated out of order.
3. Automatic namespace layout in Visual Studio .NET projects, where using sub-folders automatically implies the initial namespace that will be present for new code additions. Not a particularly great perk, but some people find this useful.
4. Separation of groups of BLLs and DALs by database or server abstraction. This is somewhat middle ground, but as a level of organization, people find this level to be more comfortable for long-term development. This allows people to identify things by where they are stored or received. But, as a trade-off, the individual projects can be more complex- though manageable via #3.

Finally, one thing I noticed is that it sounds like you have implemented nested static classes. If other people using your work are in an environment with intellisense or other environment shortcuts unavailable, they may find this setup to be highly troublesome to use. You might consider unrolling some levels of nesting into separate (or nested) namespaces instead. This is also beneficial in reducing the amount of typing required to declare items of interest, as namespace declarations only need to be present once, where static nested items need to be present every time. Your counterparts will like this.

Answer 2

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

至于静态方法与业务对象类，这可能是不寻常的，它可能有缺点，但它并不真正影响您的层是否分离。

Answer 3

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

Answer 4

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

Answer 5

我的问题是，这是否有任何架构缺陷，总是使用静态。

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

我知道人们将他们的业务层和数据访问层作为不同的项目。它作为一个项目有什么好处？所以我可以添加更多功能，或者只是这样更整洁。

优点：

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

Answer 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");
        }

    }
}