使用基于MVC的Web框架时，最佳做法是什么? [英] What are your best practices when using an MVC-based web framework?

问题描述

对于那些精通基于Web的应用程序开发人员的一些一般性问题.

A few general questions to those who are well-versed in developing web-based applications.

如何避免依赖携带"问题?据我了解，对象检索的第一点应该发生在控制器的操作方法中.从那里，您可以使用可能需要某些对象的各种模型，类，服务和组件.

How do you avoid the problem of "dependency carrying"? From what I understand, the first point of object retrieval should happen in your controller's action method. From there, you can use a variety of models, classes, services, and components that can require certain objects.

如何避免仅仅因为使用的对象需要将对象传递给另一个对象而又将其传递给另一个对象?我想避免去数据库/缓存再次获取数据，但是我也不想创建需要大量参数的函数.控制器动作应该是您创建最终需要该请求的每个对象的地方吗?

How do you avoid the need to pass an object to another just because an object it uses requires it? I'd like to avoid going to the database/cache to get the data again, but I also don't want to create functions that require a ton of parameters. Should the controller action be the place where you create every object that you'll eventually need for the request?

您在会话中存储哪些数据?我的理解是，您通常只应存储用户ID，电子邮件地址，名称和访问权限之类的内容.

What data do you store in the session? My understanding is that you should generally only store things like user id, email address, name, and access permissions.

如果用户登录时需要针对每个请求分析数据，该怎么办?您是否应该将整个用户对象存储在缓存中而不是会话中?

What if you have data that needs to be analyzed for every request when a user is logged in? Should you store the entire user object in the cache versus the session?

您是将数据检索方法放置在模型本身中还是放置在获取数据并返回模型的单独对象中?这种方法有什么优势?

Do you place your data-retrieval methods in the model itself or in a separate object that gets the data and returns a model? What are the advantages to this approach?

如果您的网站是由用户ID驱动的，那么如何对代码库进行单元测试?这就是为什么您应该将所有数据检索方法都放在一个集中的位置，以便可以在单元测试中覆盖它吗?

If your site is driven by a user id, how do you unit test your code base? Is this why you should have all of your data-retrieval methods in a centralized place so you can override it in your unit tests?

通常来说，您是否对控制器进行单元测试?我听过很多人说这是困难的，甚至是不好的做法.您对此有何看法?您究竟在控制器中测试什么?

Generally speaking, do you unit test your controllers? I have heard many say that it's a difficult and even a bad practice. What is your opinion of it? What exactly do you test within your controllers?

欢迎您分享其他有关最佳做法的信息！我总是愿意学习更多.

Any other tidbits of information that you'd like to share regarding best practices are welcome! I'm always willing to learn more.

推荐答案

• 您如何避免依赖携带"的问题?

BaseController SuperClass的良好的面向对象设计可以处理实例化常用对象等的繁重工作.使用Composite类型在调用之间共享数据是一种不常见的做法.例如.在Controller内创建您的应用程序特有的上下文对象以在进程之间共享信息并不是一个糟糕的主意.

Good object oriented design of a BaseController SuperClass can handle a lot of the heavy lifting of instantiating commonly used objects etc. Usage of Composite types to share data across calls is a not so uncommon practice. E.g. creating some Context Object unique to your application within the Controller to share information among processes isn't a terrible idea.

• 您在会话中存储什么数据?

尽量减少人类可能遇到的事情.

As few things as is humanly possible.

如果存在一些数据密集型操作，这需要大量的处理开销，并且应用程序经常需要这样做，则它是会话存储的合适候选者.是的，存储诸如用户ID和其他个性化信息之类的信息对于会话状态来说不是一个坏习惯.通常，尽管使用cookie是个性化的首选方法.永远记住，永远不要相信Cookie的内容，例如在信任读物之前先对其进行正确验证.

If there is some data intensive operation which requires a lot of overhead to process AND it's required quite often by the application, it is a suitable candidate for session storage. And yes, storage of information such as User Id and other personalization information is not a bad practice for session state. Generally though the usage of cookies is the preferred method for personalization. Always remember though to never, ever, trust the content of cookies e.g. properly validate what's read before trusting it.

• 您是将数据检索方法放置在模型本身中还是放置在获取数据并返回模型的单独对象中?

我更喜欢在我的模型中使用Repository模式.该模型本身通常包含简单的业务规则验证等，而存储库则命中业务对象以进行结果和转换/操作.市场上有很多Patterns和ORM工具，这是一个激烈争论的话题，因此有时只能归结为对工具等的熟悉...

I prefer to use the Repository pattern for my models. The model itself usually contains simple business rule validations etc while the Repository hits a Business Object for results and transformations/manipulations. There are a lot of Patterns and ORM tools out in the market and this is a heavily debated topic so it sometimes just comes down to familiarity with tools etc...

• 这种方法有什么优势?

我通过存储库模式看到的优势是您的模型很笨拙，修改起来更容易.如果它们代表业务对象(例如Web服务或数据表)，则从作为我的MVC应用程序的表示逻辑中充分抽象出对那些基础对象的更改.如果实现所有逻辑以将模型加载到模型本身中，那么我就违反了关注点分离模式.同样，这都是非常主观的.

The advantage I see with the Repository Pattern is the dumber your models are, the easier they are to modify. If they are representatives of a Business Object (such as a web service or data table), changes to those underlying objects is sufficiently abstracted from the presentation logic that is my MVC application. If I implement all the logic to load the model within the model itself, I am kind of violating a separation of concerns pattern. Again though, this is all very subjective.

• 如果您的网站是由用户ID驱动的，那么如何对代码库进行单元测试?

强烈建议在代码中尽可能使用Dependency Injection.一些IoC容器可以非常有效地处理此问题，一旦被理解，就可以极大地改善您的总体架构和设计.话虽如此，用户上下文本身应该通过某种形式的已知接口来实现，然后可以在您的应用程序中模拟".然后，您可以在测试工具中模拟所需的任何用户，并且所有相关对象都不知道它们之间的区别，因为它们只是在看一个界面.

It is highly advised to use Dependency Injection whenever possible in code. Some IoC Containers take care of this rather efficiently and once understood greatly improve your overall architecture and design. That being said, the user context itself should be implemented via some form of known interface that can then be "mocked" in your application. You can then, in your test harness, mock any user you wish and all dependent objects won't know the difference because they will be simply looking at an interface.

• 通常来说，您是否对控制器进行单元测试?

绝对.由于期望控制器返回已知的内容类型，因此使用适当的测试工具，我们可以使用实践来模拟HttpContext信息，调用Action方法并查看结果以查看它们是否符合我们的期望.有时，当结果是一些庞大的HTML文档时，这仅导致寻找HTTP状态代码，但是在JSON响应的情况下，我们可以很容易地看到action方法将按预期返回所有方案的信息

Absolutely. Since controllers are expected to return known content-types, with the proper testing tools we can use practices to mock the HttpContext information, call the Action Method and view the results to see they match our expectations. Sometimes this results in looking only for HTTP status codes when the result is some massive HTML document, but in the cases of a JSON response we can readily see that the action method is returning all scenario's information as expected

• 您在控制器中到底要测试什么?

您的控制器的任何成员和所有公开声明的成员都应进行彻底测试.

Any and all publicly declared members of your controller should be tested thoroughly.

长问题，长答案.希望这对任何人都有帮助，请仅将所有这些作为我自己的观点.这些问题很多都是宗教辩论，只要练习正确的面向对象设计，SOLID，接口编程，DRY等，您总是可以放心的.

Long question, longer answer. Hope this helps anyone and please just take this all as my own opinion. A lot of these questions are religious debates and you're always safe just practicing proper Object Oriented Design, SOLID, Interface Programming, DRY etc...

这篇关于使用基于MVC的Web框架时，最佳做法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！