IT专家数据访问层应该包含业务逻辑吗Word格式.docx

1、从设计的角度来看，我不认为把两者混在一起是一个好主意。 31If the applications is small with a short lifetime, then its not worth putting time intoabstracting the concerns in layers. In larger, long lived applications your logic/businessrules should not be coupled to the data access. It creates a maintenance nightmare as theapp

2、lication grows.如果应用程序在短时间内是小的，那么就不值得花时间将关注点抽象出来。在大型的、长期存在的应用程序中，逻辑/业务规则不应该与数据访问相耦合。随着应用程序的增长，它会造成维护噩梦。 Moving concerns to a common layer or also known as Separation of concerns, has beenaround for a while:将关注点转移到公共层或称为关注点分离，已经存在了一段时间: Wikipedia维基百科 The term separation of concerns was probably coined

3、 by Edsger W. Dijkstra in his1974 paper “On the role of scientific thought”1. 关注点分离一词可能是由 Edsger W. Dijkstra 在 1974 年的论文关于科学思想的作用中创造出来的。 For Application Architecture a great book to start with is Domain Driven Design. EricEvans breaks down the different layers of the application in detail. He also d

4、iscusses thedatabase impedance and what he calls a “Bounded Context”对于应用程序架构来说，一本伟大的书首先是领域驱动设计。Eric Evans 详细地分解了应用程序的不同层。他还讨论了数据库阻抗以及他所谓的“有界上下文” Bounded Context限界上下文 A blog is a system that displays posts from newest to oldest so that people can commenton. Some would view this as one system, or one

5、“Bounded Context.” If you subscribe toDDD, one would say there are two systems or two “Bounded Contexts” in a blog: Acommenting system and a publication system. DDD argues that each system isindependent （of course there will be interaction between the two） and should be modeledas such. DDD gives con

6、crete guidance on how to separate the concerns into theappropriate layers.博客是一个显示从最新到最古老的文章的系统，人们可以对其进行评论。有些人会认为这是一个系统，或一个“有界上下文”。如果你订阅 DDD，你会说在博客中有两个系统或两个“有界的上下文”:一个评论系统和一个发布系统。DDD 认为每个系统都是独立的（当然这两个系统之间会有交互），并且应该这样建模。DDD 给出了如何将关注点分离到合适的层的具体指导。 Other resources that might interest you:你可能感兴趣的其他资源: Do

7、main Driven Design Quickly 领域驱动设计迅速 Applying Domain DrivenDesign and Patterns 应用领域驱动设计和模式 Clean Code 干净代码 WorkingEffectively with Legacy Code 有效地使用遗留代码 RefactorUntil I had a chance toexperience The Big Ball of Mud or Spaghetti Code I had a hard time understanding whyApplication Architecture was so i

8、mportant.在我有机会体验到泥球或意大利面代码之前，我很难理解为什么应用程序架构如此重要 The right way to do things will always to be dependent on the size, availabilityrequirements and lifespan of your application. To use stored procs or not to use storedprocs. Tools such as nHibrnate and Linq to SQL are great for small to mid-size projec

9、ts.To make myself clear, Ive never used nHibranate or Linq To Sql on a large application,but my gut feeling is an application will reach a size where optimizations will need to bedone on the database server via views, Stored Procedures. etc to keep the applicationperformant. To do this work Develope

10、rs with both Development and Database skills willbe needed.正确的方法总是依赖于应用程序的大小、可用性需求和生命周期。使用存储的procs 或不使用存储的 procs对于中小型项目来说，nHibrnate 和 Linq to SQL 这样的工具非常有用。为了说明这一点，我从来没有在大型应用程序中使用 nHibranate或 Linq To Sql，但是我的直觉是一个应用程序将达到一个大小，需要通过视图、存储过程来对数据库服务器进行优化。保持应用程序的性能。要完成这项工作，开发人员需要同时具备开发和数据库技能。 4Separation o

11、f layers does not automatically mean not using stored procedures forbusiness logic. This separation is equally possible:层的分离并不意味着不为业务逻辑使用存储过程。这种分离同样是可能的: Presentation Layer: .Net, PHP, whatever表示层:。net、PHP 等等 Business Layer: Stored Procedures业务层:存储过程 Data Layer: Stored Procedures or DML数据层:存储过程或 DML

12、 This works very well with Oracle, for example, where the business layer may beimplemented in packages in a different schema from the data layer （to enforce properseparation of concerns）.这对于 Oracle 非常有效，例如，业务层可以在与数据层不同的模式下的包中实现（以实现关注点的适当分离）。 What matters is the separation of concerns, not the langua

13、ge/technology used at eachlevel.重要的是关注点的分离，而不是在每个层次上使用的语言/技术。 （I expect to get roundly flamed for this heresy!（我期望这异端邪说会引起轩然大波! 1It really depends on the requirements. Either way as long as its NOT “behind thebutton” as it were. I think stored procedure are better for “classic” client server apps wi

14、thchanging needs. A strict middle “business logic” layer is better for apps that need to bevery scalable, run on multiple database platforms, etc.这取决于需求。不管怎样，只要它不是“在按钮后面”。我认为存储过程更适合“经典”客户端服务器应用程序，它们的需求会不断变化。一个严格的中间“业务逻辑”层对于那些需要非常可扩展的应用程序来说更好，在多个数据库平台上运行等等。If you are building a layered architecture,

15、and the architecture contains a dedicatedbusiness layer, then of course you should put business logic there. However, you can askany five designers/architects/developers what business logic actually is, and get sixdifferent answers. （Hey, Im an architect myself, so I know all about on the one hand,

16、buton the other!）. Is navigating an object graph part of the data layer or business layer?Depends on which EAA patterns you are using, and on exactly how complicated/cleveryour domain objects are. Or is it perhaps even part of your presentation?如果您正在构建一个分层的体系结构，并且该体系结构包含一个专用的业务层，那么您当然应该在其中放置业务逻辑。但是，

17、您可以询问任何五位设计人员/架构师/开发人员“业务逻辑”实际上是什么，并得到六个不同的答案。（嘿，我自己就是个建筑师，因此我知道一方面，但另一方面!）导航数据层或业务层的对象图部分吗?取决于您使用的 EAA 模式，以及您的域对象到底有多复杂。或者它甚至可能是你演讲的一部分? But in more concrete terms: database development tools tend to lag behindEclipse/Visual Studio/Netbeans/; and stored procedures have never been extremelycomfortab

18、le for large-scale development. Yes, of course you can code everything inTSQL, PL/SQL c, but theres a price to pay. Whats more, the price of having severallanguages and platforms involved in one solution increases maintenance costs and delays.On the other hand, moving data access out of reach of DBA

19、s can cause other headaches,especially with shared infrastructure environments with any kind of availabilityrequirements. But overall, yes, modern tools and languages are currently moving logicfrom the data（base） layer into the application layer. Well have to see how well it worksout and scales.但更具体

20、的说法是:数据库开发工具往往落后于 Eclipse/Visual Studio/Netbeans/;存储过程对于大规模开发来说从来都不是特别舒适。当然，您可以用 TSQL、PL/SQL和 c 编写所有代码，但这是要付出代价的。此外，在一个解决方案中使用多种语言和平台的代价增加了维护成本和延迟。另一方面，将数据访问移出 DBA 的范围可能会导致其他问题，特别是在共享基础设施环境中，有任何可用性需求。但总的来说，是的，现代的工具和语言正在将逻辑从数据（基础）层转移到应用层。我们要看看它的效果和规模。 0The reason Ive seen this trend is that LINQ and

21、LINQ to SQL ORM give you a nicetype-safe alternative to stored procedures.我看到这种趋势的原因是 LINQ 和 LINQ to SQL ORM 为您提供了一个很好的类型安全的替代存储过程。 Whats “right” is whether you benefit from doing this personally.“正确”的是你是否能从中受益。Yes, business logic should be in the business logic layer. For me this is the biggestdraw

22、back of using store procedures for everything and thus moving some of the businessrules to the db, I prefer to have that logic in the BLL in have the DLL only docommunication with the db是的，业务逻辑应该位于业务逻辑层。对我来说，这是使用存储过程进行所有操作的最大缺点，因此将一些业务规则移动到 db 中，我更喜欢在 BLL 中使用该逻辑，让 DLL 只与 db 进行通信It is ALWAYS a good i

23、dea to separate your layers. I cant tell you the number of timesIve seen stored procedures that are VERY gnarly from lots of business logic written intothe sproc. Also if you modify your complex stored procedure for whatever reason, youhave the potential to break EVERYTHING that uses it.分离层总是一个好主意。我

24、不能告诉您我看到的存储过程的次数，这些存储过程与许多写入 sproc 的业务逻辑非常相似。另外，如果您出于某种原因修改了复杂的存储过程，那么您就有可能破坏使用它的所有内容。 Us devs at my company are moving to LINQ w/ the EF and dismissing the storedprocedure unless we absolutely need it. LINQ and the EF make separating our layers a loteasier.when the EF is not being difficult. But th

25、ats another rant. :我们公司的 devs 正在向 LINQ w/ the EF 转移，除非我们完全需要，否则取消存储过程。LINQ 和 EF 可以更容易地分离我们的层当 EF 不是很难的时候。但这是另一个咆哮。:There will likely always be some level of business logic in the data layer. The data itselfis a representation of some of that logic. For instance, primary keys are often created basedo

26、n business logic rules.数据层中可能始终存在某种级别的业务逻辑。数据本身就是这种逻辑的一个表示。例如，主键通常是基于业务逻辑规则创建的。 For example, if your system wont allow an order to have more than one customer ispart of the business logic, but its also present （or should be） in the Data layer.例如，如果您的系统不允许有多个客户的订单是业务逻辑的一部分，但是它也存在于数据层中（或者应该是）。 Further

27、, some kinds of business rules are best done on the database itself for efficiencyreasons. These are usually stored procedures, and thus exist in the data layer. An examplemight be a trigger that goes off if a customer has spent more than $X in a year, or if a ship-to is different from a bill-to.此外，

28、出于效率的原因，最好在数据库本身上执行一些业务规则。这些通常是存储过程，因此存在于数据层中。一个例子可能是一个触发器，如果一个客户在一年内花费了超过 X 美元，或者如果船到不同于提单到。 Many of these rules might be handled in the business layer as well, but they also need adata layer component. It depends on where your error handling is.许多规则也可以在业务层中处理，但是它们也需要一个数据层组件。这取决于错误处理的位置。Business logic in the data layer was common in client/server ap