我们正在做一个新项目，为了所有设备和浏览器的兼容性，我们决定使用 asp.net mvc 4、Html5、css 3 与我们想要使用的数据库实体框架进行通信。
我们团队中的高级成员（经理、DBA（他们也是 mvc 4、EF 的新手））要求我们编写的每一件事都将在存储过程中同时与数据库通信，以便维护变得容易。
如果我们这样（MVC4 + EF + 存储过程），它是正确的匹配吗？如果我使用 Code first 逆向工程（因为数据库表已经准备好我想这样做），我不会得到维护和性能，请回复。
下面是我们想做的流程，请指正
乍一看，ASP.NET MVC + EF + 存储过程方法在技术上没有任何问题。
但我的经验表明，这通常是巨大的矫枉过正。我看到的常见问题是开发人员和 DBA 之间的利益冲突。在大多数最坏的情况下，所有与 DB 相关的东西都由 DBA 控制，因此如果开发人员要添加/更改某些功能，他需要等待 DBA 实现它（或等待批准，这也可能需要很长时间）。
所以，我个人认为这是一种更官僚的发展方式。
我自己的观点是在开发方面更加敏捷，Code First 等工具与此相匹配。存储过程仍然可以发挥主要作用，而代码/性能优化，但不是开始。
我同意在数据库中使用存储过程是一个好方法。在数据库中集中数据验证和计算可确保数据完整性。客户端验证对用户体验很重要，但您还必须确保测试数据库中的数据有效性。使用实体框架，您可以生成与数据库中的表直接相关的实体，或者您可以设计使用插入/更新/删除操作过程而不是简单的表更新的实体。在 MVC 中，您将使用实体作为模型来管理数据交互。
祝你好运
这是我个人的看法。我相信其他人可能有不同的。既然你在问这个问题，我希望你愿意讨论，否则我不会打扰，因为这个话题就像一个宗教讨论，因为很多人都有非常强烈的意见并且不太可能改变它们。
就我个人而言，我不认为存储过程是用来编写业务逻辑的。它们应该用于编写数据访问逻辑。如果我想优化昂贵的查询（例如动态搜索），我只会使用存储过程，但仅此而已。如果你在域模型中有你的逻辑，你的性能会稍差一些，但在大多数情况下它甚至不明显。
在存储过程中编写业务逻辑的有力论据之一是，您可以通过更改存储过程轻松更改某些逻辑。但是我们真的应该在没有进行适当测试的情况下更改已部署应用程序的业务逻辑吗？如果你不小心犯了错误会发生什么？对于持续构建，现在进行部署并不是什么大问题，我认为作为一名专业开发人员，您不应该冒这个风险。
当您决定在存储过程中编写逻辑时，您放弃了所有面向对象的概念，并最终编写了一些我们可能在 10 年前编写的过程代码。C# 语言现在已经走了很长一段路，您将无法在应用程序的核心（即业务逻辑）中使用这些新的语言功能。您还失去了 Visual Studio 功能来重构代码、高级和简单的调试功能等。
我也不喜欢有触发器的想法，因为它在源代码中不可见。想象一下，您团队中的某个新成员试图在一段时间后添加一个新功能，如果他不知道触发器存在，他可能会编写一些不正确的逻辑。
如果您的应用程序包含一些复杂的业务逻辑，（我相信大多数应用程序都这样做）您应该有一个域模型，它不仅包含实体的属性，还包含您的逻辑。否则，您将陷入称为贫血数据模型的反模式。
如果您的逻辑在存储过程中，您将无法通过编写单元测试来测试您的业务逻辑。
如果您的站点真正成功，您也无法将业务逻辑部署到多个服务器，如果您将它们存储在存储过程中。
如果您的存储过程中包含所有逻辑，您也不会使用实体框架和 LINQ 的所有强大功能。如果这是您要采用的方法，您实际上不需要 ORM 映射器。
这是我会为您的项目推荐的。即使您已经拥有数据库，您仍然可以使用实体框架的代码优先方法。您可以下载 EF 代码优先逆向工程电动工具，并为您自动生成代码优先代码。这将是一次性的事情，之后如果您有更多更改，您可以直接对数据库进行操作并相应地更新代码优先代码。Fluent API 一开始有点令人困惑，但您可以从生成的代码中轻松了解这一点。
不要从控制器访问您的数据上下文。拥有一个包含所有数据访问逻辑的存储库层。您可以从控制器访问存储库。（这允许您通过模拟存储库来对代码进行单元测试）。在 asp.net 网站上有很多关于如何使用存储库模式的视频教程。
您的域模型将是从实体框架生成的实体。尝试在这些模型中包含您的业务逻辑。使用域模型模式需要一点时间。但是一旦你习惯了它，你就会开始欣赏它的好处。
希望这可以帮助。