业务逻辑层

Question

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

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

提前感谢

Answer 1

使用静态方法作为输入方法并不是一个特别大的问题。这真的取决于您是否有需要存储状态的工作区域，因为静态定义可能不允许您存储或分离状态信息。幸运的是，从使用静态声明到成员声明的倒退通常比相反的过程要轻松。如果从这些方法返回的项只对state负责，那么您甚至可能不会遇到这种问题。

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

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

1. 在开发过程中更好地分离更改，因为项目边界通常与源代码管理边界一致，允许更多的人同时在您的platform.
2. Separate部件的整个表面上工作，这些部件可以在生产中独立更新，前提是布局和界面是对每个层(无论是BLL还是DAL )给定段的哪些行为、功能和角色相交的组织。一些开发人员更喜欢根据允许用户操作给定BLL中提供的项来严格隔离组件。

然而，有些人发现大型的整体库对他们来说更好。这里有一些在这个场景中很重要的好处。

对于较旧的组件和依赖项很少更改的项目，

1. 的编译速度更快(对于C/C++开发人员来说尤其重要！)。未更改的源文件可以提示并允许编译器避免重新编译整个projects.
2. Single (或低数量)文件升级和管理，对于需要最大限度地减少给定位置的对象数量的项目而言。对于提供供其他方使用的库的人来说，这是非常可取的，因为他们不太容易受到Visual Studio .NET项目中在order.
3. Automatic命名空间布局之外发布或更新的单个项的影响，在Visual Studio.NET项目中，使用子文件夹会自动隐含将为新代码添加提供的初始命名空间。这不是一个特别好的福利，但有些人发现这种通过数据库或服务器抽象的BLL和DAL组的useful.
4. Separation。这在某种程度上是中庸之道，但作为一个组织级别，人们发现这个级别更适合长期发展。这允许人们通过存储或接收的位置来识别事物。但是，作为权衡，单个项目可以更复杂-尽管可以通过#3进行管理。

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

Answer 2

将BLL和DAL放在不同的项目中(即不同的程序集)意味着它们可以与不同的用户界面一起使用，而无需重新编译，但更重要的是，DLL的边界接口和依赖关系定义得相对良好(虽然它不能保证伟大的设计，但它至少强制实施了分离)。仍然有可能有一个逻辑分离很好的单个程序集，所以它既不是必需的，也不是足够的。

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

Answer 3

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