实用程序类可以是 MVC 框架中的模型类吗？
我正在设计一个 MVC 框架，但我不知道应该将实用程序类放在哪里。我在某处读到，它说实用程序类是模型类。这种思路是正确的还是它们是某种不同类型的类？
Im designing a MVC framework but I dont know where should I put my utility classes. I read somewhere where it said utility classes are Model Classes. Is this line of thinking correct or are they some separate type of class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于这些实用程序类正在做什么。 MVC 的主要思想是将表示层（V 和 C）与其余应用程序（M）分离。如果您的实用程序类处理与表示层相关的内容，请将它们放在适当的包中，例如 ViewHelpers 或 InputHandlers。如果实用程序函数与其他任何内容相关，请查看它们最适合模型中的哪一层，例如 DataAccess Utilities 进入 DAO 包，而 MailHelper 可能进入 Services 包，等等。
It depends on what these Utility classes are doing. The main idea of MVC is to separate the presentation layer (V and C) from the remaining application (M). If your Utility classes handle things related to the presentational layer, place them in an appropriate package, for instance ViewHelpers or InputHandlers. If the Utility functions relate to anything else, see to which layer in your model they best fit into, for instance DataAccess Utilities go into the DAO package while a a MailHelper might go into the the Services package, and so on.
模型类可以包含您的数据访问代码、应用程序逻辑。所以放在Model中就可以了。
最好的方法是在 Model 文件夹中创建一个文件夹 Utility 并将实用程序类放置在那里。
Model class can contain your data access code, application logic. so it is okay to place in Model.
The best approach is to create a folder Utility in Model folder and place utility class there.
如果它不是存储数据的表示，那么它可能不是模型类。即使如此，如果它仍然表示某种类型的存储数据，但其行为与模型的其余部分完全不同，那么无论如何，它可能不属于模型的其余部分。
实用程序函数可以是它们所使用的任何类的一部分，无论是模型、视图还是控制器。如果它们更通用一点，那么它们就有点存在于 MVC 设计“之外”。
If it isn't a representation of stored data, then it's probably not a Model class. Even then, if it still represents stored data of some sort, but behaves radically different from the rest of your Models, it may not belong with the rest of the Models, anyway.
Utility functions can be part of the whichever class they are utilities to, either Model, View or Controller. If they're a bit more generic, then they kind of live "outside" the MVC design.