好的，我正在尝试重写这个设计糟糕的ASP.NET MVC应用程序中的大部分代码。我已经阅读了很多关于许多概念和模式的内容，其中一些更为先进，但我发现自己对非常基本的员工感到困惑。
那么MVC应用程序的整体结构应该是什么？
我有一些包装数据的东西 - 我们称之为“数据层”。它可能是Repository模式的实现，也可能只是一些Entity框架上下文类或......
然后我将服务层包装业务逻辑。
提供http请求的方案应该是什么？为请求创建控制器 - ＆gt;对它的行动被执行。然后 ？我创建“数据层”的实例并将其传递给方法服务层提交更改并显示结果？
因此，所有服务（属于服务层）中的每个方法都应该将一些“数据层”类作为参数，以便它可以与“数据层”对话？或者我在构造函数中将“数据层”引用传递给服务？在这种情况下，我必须为每个请求创建新服务吗？
我读过在控制器中使用using关键字来传递“数据层”对服务的引用。另一种方法是使用依赖注入。我真的不明白其中的区别......为什么不在控制器构造函数中创建它并保持简单？
答案 0 :(得分：2)
没有冒犯@drasto，但似乎你不是重构设计不佳的现有应用程序的人，因为你自己正在努力解决相当基本的问题。至少你不应该在应用程序上进行部署。
最好与一些开发分析师交谈，他们已经完成了EF / Asp.net MVC /存储库/服务模式，并且知道他们如何相互通信以及如何实现它们。好的方面是你可以通过这种方式学到很多东西，并以正确的方式学习它。你为什么要重新发明整个车轮。
您还可以从http://www.asp.net/mvc上提供的示例中学习，这些示例将向您展示如何通过良好的应用程序架构逐步完成任务。
我只想告诉你，在一些老板开始给你带来困难之前，你宁愿先学习这些概念。只要你渴望学习，就不会承认你对这些东西知之甚少。
我在one of my answers中建立了一个Asp.net MVC应用程序架构的简化示例，它在一个非常肤浅的层面上展示了这些概念。但也可能有帮助。
答案 1 :(得分：1)
为了让你朝着正确的方向前进，我将看看我之前的问题，它可能会让你对使用依赖注入（使用UNITY）和存储库模式的简单用法的MVC结构有所了解。
MVC, EF - DataContext singleton instance Per-Web-Request in Unity
在我的示例中，控制器“注入”了所需的依赖项，在这种情况下是所需的存储库。处理完请求后，控制器随后与存储库一起处理。
此外，我建议您将数据层保存在单独的程序集（项目）中。