Bye, Bye Models 再见,模型
Is your models directory deleted yet? If not, get it out of there! Let's create a folder within our app directory that is simply named after our application. For this discussion, let's call our application QuickBill, and we'll continue to use some of the interfaces and classes we've discussed before.
删掉你的 models 目录了么?还没删就赶紧删了!我们将要在 app 目录下创建个新的目录,目录名就以我们这个应用的名字来命名,这次我们就叫 QuickBill 吧。在后续的讨论中,我们在前面写的那些接口和类都会出现。
Remember The Context 注意使用场景
Remember, if you are building a very small Laravel application, throwing a few Eloquent models in the models directory perfectly fine. In this chapter, we're primarily concerned with discovering more "layered" architecture suitable to large and complex projects.
记住,如果你在写一个很小的 Laravel 应用,那在 models 目录下写几个 Eloquent 模型其实挺合适的。但在本章节,我们主要关注如何开发更有合适“层次”架构的大型复杂项目。
So, we should have an app/QuickBill directory, which is at the same level in the application directory structure as controllers and views. We can create several more directories within QuickBill. Let's create a Repositories directory and a Billing directory. Once these directories are established, remember to register them for PSR-0 auto-loading in your composer.json file:
这样我们现在有了个 app/QuickBill 目录,它和应用目录下的其他目录如 controllers 还有 views 都是平级的。在 QuickBill 目录下我们还可以创建几个其他的目录。我们来在里面创建个 Repositories 和 Billing 目录。目录都创建好以后,别忘了在 composer.json 文件里加入PSR-0的自动载入机制:
"autoload": {
"psr-0": {
"QuickBill": "app/"
}
}
译者注:psr-0 也可以改成 psr-4, "psr-4": { "QuickBill\": "app/QuickBill" } psr-4 是比较新的建议标准,和 psr-0 具体有什么区别请自行检索。
For now, let's put our Eloquent classes at the root of the QuickBill directory. This will allow us to conveniently access them as QuickBill\User, QuickBill\Payment, etc. In the Repositories folder would belongs classes such as PaymentRepository and UserRepository, which would contain all of our data access functions such as getRecentPayments, and getRichestUser. The Billing directory would contain the classes and interfaces that work with third-party billing services like Stripe and Balanced. The folder structure would look something like this:
现在我们把继承自 Eloquent 的模型类都放到 QuickBill 目录下面。这样我们就能很方便的以 QuickBill\User, QuickBill\Payment 的方式来使用它们。Repositories 目录属于 PaymentRepository 和 UserRepository 这种类,里面包含了所有对数据的访问功能比如 getRecentPayments 和 getRichestUser 。Billing 目录应当包含调用第三方支付服务(如 Stripe 和 Balanced )的类。整个目录结构应该类似这样:
// app
// QuickBill
// Repositories
-> UserRepository.php
-> PaymentRepository.php
// Billing
-> BillerInterface.php
-> StripeBiller.php
// Notifications
-> BillingNotifierInterface.php
-> SmsBillingNotifier.php
User.php
Payment.php
What About Validation 数据验证怎么办?
Where to perform validation often stumps developers. Consider placing validation methods on your "entity" classes (like User.php and Payment.php). Possible method name might be: validForCreation or hasValidDomain. Alternatively, you could create a UserValidator class within a Validation namespace and inject that validator into your repository. Experiment with both approaches and see what you like best!
在哪儿进行数据验证常常困扰着开发人员。可以考虑将数据验证方法写进你的“实体”类里面(好比 User.php 和 Payment.php )。方法名可以设为 validForCreation 或 hasValidDomain 。或者你也可以专门创建个验证器类 UserValidator,放到 Validation 命名空间下,然后将这个验证器类注入到你的 repository 类里面。两种方式你都可以试试,看哪个你更喜欢!
By just getting rid of the models directory, you can often break down mental roadblocks to good design, allowing you to create a directory structure that is more suitable for your application. Of course, each application you build will have some similarities, since each complex application will need a data access (repository) layer, several external service layers, etc.
摆脱了 models 目录后,你通常就能克服心理障碍,实现好的设计。使得你能创建一个更合适的目录结构来为你的应用服务。当然,你建立的每一个应用程序都会有一定的相似之处,因为每个复杂的应用程序都需要一个数据访问(repository)层,一些外部服务层等等。
Don't Fear Directories 别害怕目录
Don't be afraid to create more directories to organize your application. Always break your application into small components, each having a very focused responsibility. Thinking outside of the "model" box will help. For example, as we previously discussed, you could create a Repositories directory to hold all of your data access classes.
不要惧怕建立目录来管理应用。要常常将你的应用切割成小组件,每一个组件都要有十分专注的职责。跳出“模型”的框框来思考。比如我们之前就说过,你可以创建个 Repositories 目录来存放你所有的数据访问类。