迎合API的MVC风格应用架构
我正在开发一个“社区”风格的网站，既为了乐趣又为了盈利，虽然它的美学元素进展顺利，但由于我的不确定性，我还没有认真研究应用程序逻辑。方法。
我正在创建一个 PHP 驱动的 MVC 风格框架，希望可以重用其中的组件，但是我注意到许多现有的 MVC 框架使用某种“约定优于配置”来加快整个过程。我打算运行的一些查询比 SELECT * FROMEntity_name 稍微复杂一些。
我想分层设计应用程序，以便可以对服务器进行API调用。我想，我不会把所有事情都做两次，而是在这一层之上构建我的站点控制器，以便一切都遵循标准。这将允许 Ajax 调用、远程 Web 应用程序调用等遵循与文档 Web 请求相同的请求标准化和响应路线。
无论如何，也许其中大部分都是不必要的细节，但是任何人都可以阐明这种性质的 API 分层 MVC 架构吗？由于 API 级别（模型层）是最终读取/写入数据的地方，我是否想要在此级别合并身份验证，或者将其抽象到更高级别并将其作为入口点？我还应该考虑哪些我没有提到的因素？
我知道我还有很多阅读要做，因此非常欢迎任何有关阅读材料的建议或个人经验的建议。提前致谢。
I'm working on a "community" style website, both for fun and profit, and while the aesthetic element of it is coming along nicely, I haven't yet sunk my teeth into working out the application logic for reasons of unsureness in my approach.
I'm creating an PHP powered MVC style framework which I can hopefully reuse components of, however I've noticed that many existing MVC frameworks use a sort of "convention over configuration" to expedite the whole process. Some queries I intend to run are a little more complicated than SELECT * FROM entity_name.
I want to design the application in layers, so that API calls can be made to the server. I figured instead of doing everything twice, I would build my site controllers on top of this layer, so that everything follows a standard. This will allow Ajax calls, remote web application calls, etc., to follow the same route of request normalization and response as document web requests.
Anyways, perhaps much of that is unnecessary detail, but can anyone shed some light on API layered MVC architectures of this nature? Since the API level (the model layer) is where data is ultimately read/written, would I want to incorporate authentication at this level, or abstract it to a higher level and make that the entry point? What other considerations should I make that I haven't mentioned?
I know I still have much reading to do, so any suggestions for reading materials, or advice from personal experience with this is very welcome. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是一个很好的问题。我认为我最好的选择是尽可能使用带有 REST 资源的 SOA 方法。如果您的网站获得大量点击，则可能值得将状态突变与状态暴露分开，因此第一个可以使用更复杂的 OO 方法，同时另一个可以使用简单的 DTO（以数组的形式）并使用自定义查询从数据库中检索数据。
This is a very good question. I think my best bet would be to use an SOA approach with REST resources as much as possible If your website gets a lot of hits, it might be worth segregating state mutating from state exposing, so the first can use a more complex OO approach whilst the other can use simple DTOs (in the form of arrays) and retrieve the data from the database by using custom queries.