数据访问层是否应包含业务逻辑？

我已经看到了将业务逻辑从数据访问层(存储过程,LINQ等)转移到业务逻辑组件层(如C#对象)的趋势.

这被认为是这些日子做事的"正确"方式吗？如果是这样,这是否意味着某些数据库开发人员的职位可能会被淘汰,以支持更多的中间层编码职位？(即更多的c#代码而不是更长的存储过程.)

1> Chuck Conway..：

---

如果应用程序很小且寿命很短,那么就不值得花时间来抽象层次中的问题.在较大的长期应用程序中,您的逻辑/业务规则不应与数据访问相关联.随着应用程序的增长,它会产生维护噩梦.

将问题转移到公共层或者也称为 关注点分离已经存在了一段时间:

维基百科

关注点分离可能是Edsger W. Dijkstra在他1974年发表的论文"论科学思想的作用" 1中创造的.

对于应用程序架构,一本很好的书是Domain Driven Design.Eric Evans详细介绍了应用程序的不同层.他还讨论了数据库阻抗以及他所谓的"有界上下文"

有界上下文

博客是一个显示从最新到最旧的帖子的系统,以便人们可以发表评论.有些人会将此视为一个系统,或一个"有界上下文".如果您订阅DDD,可以说博客中有两个系统或两个"Bounded Contexts":评论系统和发布系统.DDD认为每个系统都是独立的(当然两者之间会有相互作用),因此应该对其进行建模.DDD就如何将问题分成适当的层提供了具体的指导.

您可能感兴趣的其他资源:

领域驱动设计快速

应用领域驱动设计和模式

清洁代码

有效地使用遗留代码

重构

在我有机会体验The Big Ball of Mud或Spaghetti Code之前,我很难理解为什么Application Architecture如此重要......

正确的做事方式始终取决于应用程序的大小,可用性要求和使用寿命.要使用存储过程或不使用存储过程... nHibrnate和Linq to SQL等工具非常适合中小型项目.为了使自己清楚,我从未在大型应用程序上使用过nHibranate或Linq To Sql,但我的直觉是应用程序将达到需要通过视图,存储过程等在数据库服务器上进行优化的大小.保持应用程序的性能.要做这项工作,将需要具有开发和数据库技能的开发人员.

---

在与一些更复杂的架构更紧密地合作之后,我可以说这是一个比我更好的答案.

2> Matthew Olen..：

---

数据访问逻辑属于数据访问层,业务逻辑属于业务层.从设计的角度来看,我不认为将两者混合起来是一个好主意.

---

也许不是,但这并不排除在存储过程中构建业务层,也不排除使用C#代码.

---

对于任何未来的读者,请小心这个建议.这非常接近贫血领域模型.Foo相关的方法应该在Foo的模型中.除非你有充分的理由,否则不要将实体留作吸气剂和制定者的袋子,并将他们的方法放在另一层.在过去一年中与一些更为复杂的系统密切合作后学到的经验教训.