IT专家数据访问层应该包含业务逻辑吗Word格式.docx
《IT专家数据访问层应该包含业务逻辑吗Word格式.docx》由会员分享，可在线阅读，更多相关《IT专家数据访问层应该包含业务逻辑吗Word格式.docx（18页珍藏版）》请在冰豆网上搜索。
从设计的角度来看，我不
认为把两者混在一起是一个好主意。
31
Iftheapplicationsissmallwithashortlifetime,thenit’snotworthputtingtimeinto
abstractingtheconcernsinlayers.Inlarger,longlivedapplicationsyourlogic/business
rulesshouldnotbecoupledtothedataaccess.Itcreatesamaintenancenightmareasthe
applicationgrows.
如果应用程序在短时间内是小的，那么就不值得花时间将关注点抽象出来。
在大
型的、长期存在的应用程序中，逻辑/业务规则不应该与数据访问相耦合。
随着应用
程序的增长，它会造成维护噩梦。
MovingconcernstoacommonlayeroralsoknownasSeparationofconcerns,hasbeen
aroundforawhile:
将关注点转移到公共层或称为关注点分离，已经存在了一段时间:
Wikipedia
维基百科
ThetermseparationofconcernswasprobablycoinedbyEdsgerW.Dijkstrainhis
1974paper“Ontheroleofscientificthought”1.
关注点分离一词可能是由EdsgerW.Dijkstra在1974年的论文《关于科学思想的
作用》中创造出来的。
ForApplicationArchitectureagreatbooktostartwithisDomainDrivenDesign.Eric
Evansbreaksdownthedifferentlayersoftheapplicationindetail.Healsodiscussesthe
databaseimpedanceandwhathecallsa“BoundedContext”
对于应用程序架构来说，一本伟大的书首先是领域驱动设计。
EricEvans详细地
分解了应用程序的不同层。
他还讨论了数据库阻抗以及他所谓的“有界上下文”
BoundedContext
限界上下文
Ablogisasystemthatdisplayspostsfromnewesttooldestsothatpeoplecancomment
on.Somewouldviewthisasonesystem,orone“BoundedContext.”Ifyousubscribeto
DDD,onewouldsaytherearetwosystemsortwo“BoundedContexts”inablog:
A
commentingsystemandapublicationsystem.DDDarguesthateachsystemis
independent（ofcoursetherewillbeinteractionbetweenthetwo）andshouldbemodeled
assuch.DDDgivesconcreteguidanceonhowtoseparatetheconcernsintothe
appropriatelayers.
博客是一个显示从最新到最古老的文章的系统，人们可以对其进行评论。
有些人
会认为这是一个系统，或一个“有界上下文”。
如果你订阅DDD，你会说在博客中有
两个系统或两个“有界的上下文”:
一个评论系统和一个发布系统。
DDD认为每个系
统都是独立的（当然这两个系统之间会有交互），并且应该这样建模。
DDD给出了如
何将关注点分离到合适的层的具体指导。
Otherresourcesthatmightinterestyou:
你可能感兴趣的其他资源:
DomainDrivenDesignQuickly领域驱动设计迅速ApplyingDomainDriven
DesignandPatterns应用领域驱动设计和模式CleanCode干净代码Working
EffectivelywithLegacyCode有效地使用遗留代码RefactorUntilIhadachanceto
experienceTheBigBallofMudorSpaghettiCodeIhadahardtimeunderstandingwhy
ApplicationArchitecturewassoimportant...
在我有机会体验到泥球或意大利面代码之前，我很难理解为什么应用程序架构如
此重要……
Therightwaytodothingswillalwaystobedependentonthesize,availability
requirementsandlifespanofyourapplication.Tousestoredprocsornottousestored
procs...ToolssuchasnHibrnateandLinqtoSQLaregreatforsmalltomid-sizeprojects.
Tomakemyselfclear,I’veneverusednHibranateorLinqToSqlonalargeapplication,
butmygutfeelingisanapplicationwillreachasizewhereoptimizationswillneedtobe
doneonthedatabaseserverviaviews,StoredProcedures..etctokeeptheapplication
performant.TodothisworkDeveloperswithbothDevelopmentandDatabaseskillswill
beneeded.
正确的方法总是依赖于应用程序的大小、可用性需求和生命周期。
使用存储的
procs或不使用存储的procs…对于中小型项目来说，nHibrnate和LinqtoSQL这样
的工具非常有用。
为了说明这一点，我从来没有在大型应用程序中使用nHibranate
或LinqToSql，但是我的直觉是一个应用程序将达到一个大小，需要通过视图、存
储过程来对数据库服务器进行优化。
保持应用程序的性能。
要完成这项工作，开发
人员需要同时具备开发和数据库技能。
4
Separationoflayersdoesnotautomaticallymeannotusingstoredproceduresfor
businesslogic.Thisseparationisequallypossible:
层的分离并不意味着不为业务逻辑使用存储过程。
这种分离同样是可能的:
PresentationLayer:
.Net,PHP,whatever
表示层:
。
net、PHP等等
BusinessLayer:
StoredProcedures
业务层:
存储过程
DataLayer:
StoredProceduresorDML
数据层:
存储过程或DML
ThisworksverywellwithOracle,forexample,wherethebusinesslayermaybe
implementedinpackagesinadifferentschemafromthedatalayer（toenforceproper
separationofconcerns）.
这对于Oracle非常有效，例如，业务层可以在与数据层不同的模式下的包中实现
（以实现关注点的适当分离）。
Whatmattersistheseparationofconcerns,notthelanguage/technologyusedateach
level.
重要的是关注点的分离，而不是在每个层次上使用的语言/技术。
（Iexpecttogetroundlyflamedforthisheresy!
（我期望这异端邪说会引起轩然大波!
1
Itreallydependsontherequirements.Eitherwayaslongasit’sNOT“behindthe
button”asitwere.Ithinkstoredprocedurearebetterfor“classic”clientserverappswith
changingneeds.Astrictmiddle“businesslogic”layerisbetterforappsthatneedtobe
veryscalable,runonmultipledatabaseplatforms,etc.
这取决于需求。
不管怎样，只要它不是“在按钮后面”。
我认为存储过程更适合“经
典”客户端服务器应用程序，它们的需求会不断变化。
一个严格的中间“业务逻辑”层
对于那些需要非常可扩展的应用程序来说更好，在多个数据库平台上运行等等。
Ifyouarebuildingalayeredarchitecture,andthearchitecturecontainsadedicated
businesslayer,thenofcourseyoushouldputbusinesslogicthere.However,youcanask
anyfivedesigners/architects/developerswhat‘businesslogic’actuallyis,andgetsix
differentanswers.（Hey,I’manarchitectmyself,soIknowallabout‘ontheonehand,but
ontheother’!
）.Isnavigatinganobjectgraphpartofthedatalayerorbusinesslayer?
DependsonwhichEAApatternsyouareusing,andonexactlyhowcomplicated/clever
yourdomainobjectsare.Orisitperhapsevenpartofyourpresentation?
如果您正在构建一个分层的体系结构，并且该体系结构包含一个专用的业务层，
那么您当然应该在其中放置业务逻辑。
但是，您可以询问任何五位设计人员/架构师
/开发人员“业务逻辑”实际上是什么，并得到六个不同的答案。
（嘿，我自己就是个建
筑师，因此我知道‘一方面，但另一方面’!
）导航数据层或业务层的对象图部分吗?
取决于您使用的EAA模式，以及您的域对象到底有多复杂。
或者它甚至可能是你
演讲的一部分?
Butinmoreconcreteterms:
databasedevelopmenttoolstendtolagbehind
Eclipse/VisualStudio/Netbeans/;
andstoredprocedureshaveneverbeenextremely
comfortableforlarge-scaledevelopment.Yes,ofcourseyoucancodeeverythingin
TSQL,PL/SQLc,butthere’sapricetopay.What’smore,thepriceofhavingseveral
languagesandplatformsinvolvedinonesolutionincreasesmaintenancecostsanddelays.
Ontheotherhand,movingdataaccessoutofreachofDBA’scancauseotherheadaches,
especiallywithsharedinfrastructureenvironmentswithanykindofavailability
requirements.Butoverall,yes,moderntoolsandlanguagesarecurrentlymovinglogic
fromthedata（base）layerintotheapplicationlayer.We’llhavetoseehowwellitworks
outandscales.
但更具体的说法是:
数据库开发工具往往落后于Eclipse/VisualStudio/Netbeans/;
存
储过程对于大规模开发来说从来都不是特别舒适。
当然，您可以用TSQL、PL/SQL
和c编写所有代码，但这是要付出代价的。
此外，在一个解决方案中使用多种语言
和平台的代价增加了维护成本和延迟。
另一方面，将数据访问移出DBA的范围可
能会导致其他问题，特别是在共享基础设施环境中，有任何可用性需求。
但总的来
说，是的，现代的工具和语言正在将逻辑从数据（基础）层转移到应用层。
我们要看
看它的效果和规模。
0
ThereasonI’veseenthistrendisthatLINQandLINQtoSQLORMgiveyouanice
type-safealternativetostoredprocedures.
我看到这种趋势的原因是LINQ和LINQtoSQLORM为您提供了一个很好的类型
安全的替代存储过程。
What’s“right”iswhetheryoubenefitfromdoingthispersonally.
“正确”的是你是否能从中受益。
Yes,businesslogicshouldbeinthebusinesslogiclayer.Formethisisthebiggest
drawbackofusingstoreproceduresforeverythingandthusmovingsomeofthebusiness
rulestothedb,IprefertohavethatlogicintheBLLinhavetheDLLonlydo
communicationwiththedb
是的，业务逻辑应该位于业务逻辑层。
对我来说，这是使用存储过程进行所有操
作的最大缺点，因此将一些业务规则移动到db中，我更喜欢在BLL中使用该逻
辑，让DLL只与db进行通信
ItisALWAYSagoodideatoseparateyourlayers.Ican’ttellyouthenumberoftimes
I’veseenstoredproceduresthatareVERYgnarlyfromlotsofbusinesslogicwritteninto
thesproc.Alsoifyoumodifyyourcomplexstoredprocedureforwhateverreason,you
havethepotentialtobreakEVERYTHINGthatusesit.
分离层总是一个好主意。
我不能告诉您我看到的存储过程的次数，这些存储过程
与许多写入sproc的业务逻辑非常相似。
另外，如果您出于某种原因修改了复杂的
存储过程，那么您就有可能破坏使用它的所有内容。
UsdevsatmycompanyaremovingtoLINQw/theEFanddismissingthestored
procedureunlessweabsolutelyneedit.LINQandtheEFmakeseparatingourlayersalot
easier...whentheEFisnotbeingdifficult.Butthat’sanotherrant.:
我们公司的devs正在向LINQw/theEF转移，除非我们完全需要，否则取消存储
过程。
LINQ和EF可以更容易地分离我们的层……当EF不是很难的时候。
但这是
另一个咆哮。
:
Therewilllikelyalwaysbesomelevelofbusinesslogicinthedatalayer.Thedataitself
isarepresentationofsomeofthatlogic.Forinstance,primarykeysareoftencreatedbased
onbusinesslogicrules.
数据层中可能始终存在某种级别的业务逻辑。
数据本身就是这种逻辑的一个表
示。
例如，主键通常是基于业务逻辑规则创建的。
Forexample,ifyoursystemwon’tallowanordertohavemorethanonecustomeris
partofthebusinesslogic,butit’salsopresent（orshouldbe）intheDatalayer.
例如，如果您的系统不允许有多个客户的订单是业务逻辑的一部分，但是它也存
在于数据层中（或者应该是）。
Further,somekindsofbusinessrulesarebestdoneonthedatabaseitselfforefficiency
reasons.Theseareusuallystoredprocedures,andthusexistinthedatalayer.Anexample
mightbeatriggerthatgoesoffifacustomerhasspentmorethan$Xinayear,orifaship-
toisdifferentfromabill-to.
此外，出于效率的原因，最好在数据库本身上执行一些业务规则。
这些通常是存
储过程，因此存在于数据层中。
一个例子可能是一个触发器，如果一个客户在一年
内花费了超过X美元，或者如果船到不同于提单到。
Manyoftheserulesmightbehandledinthebusinesslayeraswell,buttheyalsoneeda
datalayercomponent.Itdependsonwhereyourerrorhandlingis.
许多规则也可以在业务层中处理，但是它们也需要一个数据层组件。
这取决于错
误处理的位置。
Businesslogicinthedatalayerwascommoninclient/serverap
升级会员 