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