我应该如何在我的PHP应用程序中拆分MVC模型？

问题描述：

I have a PHP site based on a simple MVC principle. I currently have one model file with many functions for getting data from the database. However, it's becoming a little monolithic now so I'd like to split it into separate models. The question is - what's the best way to do this?

Is it a good idea to create a class for each table, so I can return an object or array of objects (say, a list of articles)? Or is it simpler to create objects/arrays on the fly?

我有一个基于简单MVC原则的PHP站点。我目前有一个模型文件，其中包含许多用于从数据库中获取数据的函数。然而，它现在变得有点单片，所以我想把它分成不同的模型。问题是 - 最好的方法是什么？ p>

为每个表创建一个类是一个好主意，所以我可以返回一个对象或对象数组（比如说，文章清单）？或者在运行中创建对象/数组更简单吗？ p> div>

答

I would create a Model for each table. A monolithic table is a nightmare to maintain 6 months down the road as you know now.

as far as valya's example: i would create a Users model and a Marriages model with all their usual insert/edit/delete/get functions on top of customized functions like isMarried() where it calls the Marriages model. ie

class UserModel {
    public function isMarried($user_id) {
        return $marriages->findById($user_id);
    }
}

whichever way you decide to go try to keep it simple. simple is better than clever in the long run.

答

It depends :)

I think It's a good idea to create a class for each object (not for each table). For example, If you have tables:

Users(uid, name, ...)
Marriages(h_uid, w_uid)

It will be cool to create only User class with some methods like ->isMarried()

答

You can use an ORM, like Doctrine.

答

For PHP, I would create classes based on data usage and access patterns. Have one class that contains a "core" set of functions that are likely used on every hit. Then have one class for each "section" of your app, which would load when needed.

This isn't the "proper" or best object oriented approach, but it keeps the overhead down. Having a class for each object would be great and neat, but PHP has to load and create everything from scratch on every hit. The more files that need to be loaded and objects created, the slower PHP gets.

You shouldn't need to access a dozen different files just to respond to an Ajax call to find out if someone is married.

答

I would step back and look at your application apart from the database for a sec. If the database were never involved, what would your application look like? What would your classes be called? What sort of objects would you have? What would they do? Design your application and then decide how its data should be persisted.

What I'm driving towards, I think, is something more like the class-per-table design mentioned above, though I would turn it around and say it's table-per-class. Design your system, then figure out the best way to represent your data in the DB. Doctrine is a good system for doing this, but you can do it just fine with more manual database steps, as well.

And as for the overhead involved, it really depends on how many different classes you would be instantiating in each request. Yes, you could save overhead by using generic "fetcher" classes that don't really return objects at all (or that return objects that are hodge-podges of a bunch of should-be-separate-objects), but then the argument could be carried through to not using classes of any kind at all. There's definitely extra overhead whenever you use object-oriented programming of any kind, or function libraries, or anything else that you have to include. But the reason we don't have make single-file PHP sites is because the overhead incurred is bearable, and it's much more bearable than the developer overhead incurred by going the other way.

我应该如何在我的PHP应用程序中拆分MVC模型？

相关推荐