【问题标题】:MVC code structuring best practice questions [closed]MVC 代码结构最佳实践问题 [关闭]
【发布时间】:2012-07-28 00:42:11
【问题描述】:

我正在尝试改进我的代码结构,以便我可以就以下几点和有关如何处理主要服务的问题获得一些意见。

  1. 服务不应依赖于表示层,因此通过构造函数等将 httpcontext 之类的内容传递到服务/服务函数是一种不好的做法,对吗?

  2. 不应该让服务相互引用吗?他们应该只像存储库依赖那样“向下”工作吗?还是认为可以?

  3. 服务是否仅包含与过滤和处理来自数据库/存储库的信息直接相关的功能,或者是否可以考虑例如专门用于加密和生成随机字符串/密码的类或依赖方功能的类处理提供程序还有服务吗?或者他们/一个可能会被视为实用程序类?

  4. 是否有一种良好且可接受的方式来操作服务内的会话,或者应该将其传递给控制器​​并在那里处理?

【问题讨论】:

  • 嗨,欢迎来到 stackoverflow。我意识到 MVC 是一个棘手的主题,但你的问题远非广泛。如果您阅读常见问题解答 (stackoverflow.com/faq#dontask)If you can imagine an entire book that answers your question, you’re asking too much. 有很多关于 mvc 的书籍。我的建议是尝试制作一个 mvc 框架,然后在它们弹出时提出具体问题。没有任何人可以给你答案,这将有助于 MVC 变得有意义。这种理解是从经验中形成的。
  • 您说的是 ASP.NET MVC 还是一般的 MVC 模式?你的标签让人困惑,因为它们不是一回事。
  • 您好,感谢您的欢迎 ;) 我在谈论 asp.net MVC,我谈论的范围很广的原因是我正在寻找更多的通用指南(如果可能的话)然后是准确的回答一个具体问题。 Luxspes 似乎对我正在寻找的答案水平做出了回应,所以如果现在有人对它有任何有用的补充,我对这个答案很满意。在旁注中,我看到人们推荐这本书“清洁代码”,所以我想看看它是否有助于我进一步深入这个主题。

标签: c# asp.net-mvc agile


【解决方案1】:

服务不应该依赖于表示层,所以 将诸如 httpcontext 之类的东西传递给服务/服务函数 通过构造函数和类似方法是一种不好的做法,正确

如果可以避免,请避免。但这取决于,如果它是表示层的服务,那么它就可以了。

不应该让服务相互引用吗?他们应该只 像存储库依赖一样“向下”工作?或者那是 还可以吗?

如果可以避免,请避免。这取决于你的架构,例如,如果你在 asp.net mvc 中工作,你会很好地避免这种情况,并将协调你的多个服务的代码保持在 Controller 级别

服务是否只包含直接相关的功能? 过滤和处理来自数据库/存储库的信息或 例如,可以考虑一个专门用于加密的类 并生成随机字符串/密码或类处理提供程序 依赖方功能也是服务吗?或者他们/一个会是 也许被认为是实用程序类?

您可以使用服务来过滤和处理来自数据库/存储库的信息,或者您也可以创建一个专门用于加密和生成随机字符串/密码的服务。服务是类,所以它们遵循Single Responsability Principle

是否有一种良好且可接受的方式来操作 服务还是应该传递给控制器​​并在那里处理?

如果您的服务是无状态的,那么扩展会更好,但如果您将不得不处理会话或其他生命周期的东西,并且您正在使用 .net 构建 Web 系统,那么您可以做的最好的事情就是使用 asp。 net mvc,与Unity集成,得到Inversion Of Control,这样就可以使用life time managers处理会话

【讨论】:

    猜你喜欢
    • 2013-07-22
    • 2011-09-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-25
    • 1970-01-01
    相关资源
    最近更新 更多