Reputation: 5681
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)
Upvotes: 0
Views: 153
Reputation: 57877
You're absolutely right to use it that way.
The M
in MVC
is supposed to be abstract. That's why we call it a Model
instead of a Database, XML File, or Domain Service or Web Service.
Upvotes: 1