我正在使用 ASP.NET 和 Telerik 控件 (v2009 q2) 来编程数据驱动的应用程序。
我有一个名为 BLL 的类，它包含（几乎仅）静态类，这些类返回不同的对象，并以一些 id 作为参数。通常以列表形式返回对象组。
我的问题是，总是使用静态是否存在任何架构缺陷。我知道人们将业务层和数据访问层作为不同的项目。作为一个项目有什么好处？所以我可以添加更多功能或者这样更整洁。
提前致谢
使用静态方法作为入口方法并不是一个特别大的问题。这实际上取决于您是否有需要存储状态的工作领域，因为静态定义可能不允许您存储或分离状态信息。幸运的是，从使用静态声明退回到成员声明通常比相反的过程要轻松得多。如果从此类方法返回的项目单独负责状态，您甚至可能不会遇到此问题。
单独的库/项目对于划分工作单元很有用。正如 Dave Swersky 所提到的，尽管您可能会看到静态成员变量的怪癖，特别是在多线程应用程序中，但并没有严格要求所有内容都必须分离到不同的库中。
拥有单独的库还可以为您带来以下好处：
- 在开发过程中更好地分离变更，因为项目边界通常与源代码控制边界一致，从而允许更多的人在整个平台上同时工作。
- 如果布局和接口兼容，则可以在生产中独立更新单独的部件。
- 更好地组织每一层（无论是 BLL 还是 DAL）给定段的行为、功能和角色的交叉点。一些开发人员更喜欢根据允许用户对给定 BLL 中提供的项目进行操作的内容来严格隔离组件。
然而，一些团体发现大型整体库对他们来说效果更好。以下是在这种情况下很重要的一些好处。
- 对于旧组件和依赖项很少更改的项目，编译时间更快（对于 C/C++ 开发人员尤其重要！）。总体而言，不更改的源文件可以提示并允许编译器避免重新编译整个项目。
- 单个（或低计数）文件升级和管理，适用于必须最大限度地减少给定位置存在的对象数量的项目。对于提供库供其他方使用的人来说，这是非常理想的，因为人们不太容易受到个别项目无序发布或更新的影响。
- Visual Studio .NET 项目中的自动命名空间布局，其中使用子文件夹会自动暗示将为新代码添加提供的初始命名空间。这不是一个特别好的福利，但有些人发现这很有用。
- 通过数据库或服务器抽象来分离 BLL 和 DAL 组。这有点中间立场，但作为组织的一个级别，人们发现这个级别更适合长期发展。这使得人们可以通过存储或接收物品的位置来识别物品。但是，作为权衡，各个项目可能会更复杂——尽管可以通过#3 进行管理。
最后，我注意到的一件事是，听起来您已经实现了嵌套静态类。如果使用您的工作的其他人处于智能感知或其他环境快捷方式不可用的环境中，他们可能会发现此设置使用起来非常麻烦。您可能会考虑将某些级别的嵌套展开到单独的（或嵌套的）命名空间中。这也有利于减少声明感兴趣的项所需的输入量，因为命名空间声明只需要出现一次，而静态嵌套项每次都需要出现。您的同行会喜欢这个。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
