业务逻辑层
我正在使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
使用静态方法作为入口方法并不是一个特别大的问题。这实际上取决于您是否有需要存储状态的工作领域,因为静态定义可能不允许您存储或分离状态信息。幸运的是,从使用静态声明退回到成员声明通常比相反的过程要轻松得多。如果从此类方法返回的项目单独负责状态,您甚至可能不会遇到此问题。
单独的库/项目对于划分工作单元非常有用。正如 Dave Swersky 所提到的,尽管您可能会看到静态成员变量的怪癖,特别是在多线程应用程序中,但并没有严格要求所有内容都必须分离到不同的库中。
拥有单独的库还可以为您带来以下好处:
然而,一些团体发现大型整体库对他们来说效果更好。以下是在这种情况下很重要的一些好处。
最后,我注意到的一件事是,听起来您已经实现了嵌套静态类。如果使用您的工作的其他人处于智能感知或其他环境快捷方式不可用的环境中,他们可能会发现此设置使用起来非常麻烦。您可能会考虑将某些级别的嵌套展开到单独的(或嵌套的)命名空间中。这也有利于减少声明感兴趣的项所需的输入量,因为命名空间声明只需要出现一次,而静态嵌套项每次都需要出现。您的同行会喜欢这个。
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:
However, some parties have found that large monolithic libraries work better for them. Here are some benefits that are important in this scenario.
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.
将 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.
如果您的应用程序是无状态的,那么全静态方法/类应该不是问题。但是,如果您的应用程序是多线程的并且 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.
单独项目的优点之一是,如果您需要更新应用程序但仅更改 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
这种方法的一个缺陷是不能将接口应用于静态方法。一种可能的解决方法是使用单例模式,尽管您需要小心线程问题。
优点:
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.
Advantages: