将 ASP MVC 工作流程/框架用于非 MVC 应用程序
我正在为旧版 Web 应用程序构建一个管理 Web 界面。 “超级用户”使用此接口来管理我通常在数据库中手动执行的后端内容。这可以是报告生成的优先级（应用程序生成每个报告需要 10-15 分钟，有时我们需要一份报告在队列中的所有其他报告之前）、用户管理等。
我的想法是让 MVC 中的 M 变得有点抽象。在数据库中，报告有点抽象。但在我看来，如果我“帮助”Report 实体工作，它就可以很好地适应 MVC 术语。报告可以轻松地进行 CRUD 操作，只需进行一些定制以适应数据库即可。
这是使用 MVC 的不好方法吗？ M 作为领域模型（某种）而不是实际的数据库模型是否存在问题？
（是的，我是 MVC 新手；）。所有这一切都在 ASP.NET MVC 3 中，带有 SS2k8 sql 后端）
I'm building a admin-webinterface for a legacy webapplication. This interface is to be used by "superusers" for administrating backend stuff that I usually do manually in the db. This can be things like prioritizing report generation (The app generates reports which take 10-15 minutes each, sometimes we need one report before all the other ones in the queue), user management and such.
What I was thinking was making the M in the MVC a bit abstract. In the DB, a report is a bit abstract. But in my head, the Report entity can lend itself well to MVC terminology if I "help" it work. A report could easily have CRUD-actions, just with a bit of tailoring to fit into the db.
Is this a bad way to use MVC? Is there a problem with the M being the Domain Model (of sorts) instead of an actual DB Model?
(And yes, I'm new to MVC ;). And all this is in ASP.NET MVC 3, with a SS2k8 sql backend)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你这样使用它是绝对正确的。
MVC中的M应该是抽象的。这就是为什么我们将其称为模型，而不是数据库、XML 文件、域服务或 Web 服务。You're absolutely right to use it that way.
The
MinMVCis supposed to be abstract. That's why we call it aModelinstead of a Database, XML File, or Domain Service or Web Service.