业务逻辑层

发布于 2024-08-11 15:16:15 字数 221 浏览 4 评论 0原文

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

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

提前致谢

I am programming data driven applications using asp.net with telerik controls (v2009 q2).
I have a class named BLL which contains (almost only) static classes that return different objects taking some id as parameter. The generally return group of objects as Lists.

My question is that are there any architrectural flaws to this, always using static. I know people make their Busines Layer and DataAccess layer as different projects. What is the advantage of it being a project ? So I can add more functionality or just it is tidier that way.

Thanks in advance

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

善良天后 2024-08-18 15:16:15

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

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

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

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

然而,一些团体发现大型整体库对他们来说效果更好。以下是在这种情况下很重要的一些好处。

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

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

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.

傲世九天 2024-08-18 15:16:15

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

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

Having the BLL and DAL in separate projects (i.e. separate assemblies) means that they can be used with different user interfaces without re-compiling, but more importantly that the boundary interfaces and dependencies of the DLLs are relatively well-defined (although it doesn't guarantee a great design, it at least enforces a separation). It's still possible to have a single assembly with great logical separation, so it's not required nor sufficient.

As far as the static methods versus business object classes, that could be unusual and it could have drawbacks, but it doesn't really affect whether your layers are separated or not.

瑾夏年华 2024-08-18 15:16:15

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

If your application is stateless, all-static methods/classes shouldn't be a problem. However, if your app is multi-threaded and the BLL does read and commit, you could run into thread safety issues.

池予 2024-08-18 15:16:15

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

One advantage of a separate project is that if you need to update your application but only change the BLL, you can make your change, recompile the DLL and drop it in the bin folder where the application is deployed in IIS without having to redeploy the whole web application

人│生佛魔见 2024-08-18 15:16:15

我的问题是有没有
建筑缺陷总是如此
使用静态。

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

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

优点:

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

My question is that are there any
architrectural flaws to this, always
using static.

One flaw with that approach is that you can't apply Interfaces to static methods. A possible work-around is to use a Singleton pattern, although you will need to be careful about threading issues.

I know people make their Busines Layer
and DataAccess layer as different
projects. What is the advantage of it
being a project ? So I can add more
functionality or just it is tidier
that way.

Advantages:

  1. Easier for multiple developers to work on (depending on your environment and source control)
  2. Forced separation of logic / protection levels from the rest of your solution
  3. Easier to group and manage if your BLL gets large
会发光的星星闪亮亮i 2024-08-18 15:16:15
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");
        }

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

    }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文