MVC Mayhem; Sorting out Model responsibility and structure

My understanding of MVC-type architectures over the last few weeks/months has advanced (I'd say) considerably, and I owe most of my thanks to fellow SO enthusiasts; so, thank you!

I'm still challenged by something though, the Model. So far I've sorted out and created;

• A simple Request object, that consolidates request data (GET/POST/etc. params, HTTP headers, etc.)
• A simple Response object, that collects response data (HTML, JSON, HTTP headers, etc.)
• A fancy Router that resolves URIs against a regex-powered routing table, validates them based on Controller file/class existence/inheritance, and updates the Request object with any supplementary parameters.
• A simple Dispatcher object that sets up the working environment, creates and initializes the necessary Controller, and sends it a Request and Response object to work with.

Now the Model.

I understand that in many (some) circumstances the Model is merely representational of it's associated entity, the table, with CRUD methods (addUser(), deleteUser(), etc.) In others there are further levels of abstraction, preventing controllers from accessing finer-grain CRUD functionality, consolidating methods (replaceUser() - deletes, adds, then returns user data)

I'm wondering what my best course of action is; for a few specific reasons.

I've created a Gateway class that acts as a proxy to an intended Model, performing ACL checks (using the Acl object, a special case "Model") using the Request and desired method and arguments as parameters for the check. The Controller is responsible for determining the outcome of a failed ACL check (display all but that da开发者_StackOverflow社区ta, redirect, etc.)

I've also introduced an (and I've referred to it as hybrid REST/RPC previously, but I believe that's incorrect as my resource URI architecture is out-the-window) RPC API layer. An API call consists of a method, arguments, and request parameters, is managed by the special ApiController and is fed like a normal Model call to the Gateway.

It seems to me like the best way to facilitate data access, would be a (uh-oh) single enormous model object, disregarding any ORM, that maintains all database interaction methods, proving simplicity for managing the Gateway/ACL/Model relationship. No, that sounds wrong.

Given these architectural choices, what may be my best choice for modeling my, um.. Model? Have I really thrown caution and best-practice to the wind with the aforementioned design choices?

Perhaps it's just semantics but I would say that The Model is the representation of the the data, the classes (and by extension the objects) that encapsulate the entities in your application. There's another, missing piece, which I would call the persistence or data access layer (DAL). MVC as an abstraction doesn't really concern itself with persistence because you don't actually have to have persistence to develop using the MVC pattern. In (almost?) all web applications using MVC, you do have a database and thus do need a persistence layer. The persistence layer understands The Model and makes it available to the controller, but it's not really part of the model.

If you separate out the concepts of inserting/retrieving/updating the data into the persistence layer, what you're left with are the containers and associated business/validation logic that encapsulate the representation of your applications entities. These should be relatively small, well-focused, and only interdependent on the actual data dependencies between your entities. This small models, one per entity, in total comprise The Model for your application. Your persistence layer (DAL/ORM), too, is not particularly large, but rather is focuses solely on interacting with the database to obtain/store the models.