数据在一侧,API 在另一侧公开数据 -> 2 个不同的项目都有自己的 ORM 层?

发布于 2024-11-17 20:33:41 字数 608 浏览 1 评论 0原文

这不是一个经典的编程语言问题,但它让我很忙,所以我想我不妨利用 Stack 的经验:-)

我有一个可以接受来自各种来源的测量数据的系统。这些数据消息被放入队列中。 现在我需要构建:

  1. 一个定期阅读消息的系统 该队列并保留数据 将它们内的数据库(可能 调用的 PHP 脚本 cron)
  2. 将数据公开给外部各方的系统(作为 API/webservice)

但是,数据库方案肯定会改变,所以我想我会尝试用 Doctrine 来抽象这一部分。

现在,如果我使用两个项目,我将必须在两个项目中使用 Doctrine,它们都具有反映下面数据库中相同表的对象。因此,如果数据库发生变化,我需要更改两个项目的模型。这感觉不对。

我可以使用一个项目和一个 ORM,这样如果有更改,我只需更改一层。然而,然后我有一个使用该模型的脚本和一个网络服务,都在同一个“项目”中。

简单地思考“项目”,例如 Netbeans。我想我会创建一个包含 Doctrine 对象的“model”文件夹、一个由 cron 访问的“script”文件夹和一个由网络服务器访问的“api”文件夹。

一个项目有不同的应用程序感觉很奇怪,但感觉只有一层 ORM 层也是最好的。做什么才是正经事呢?

This isn't a classic programming language question, but it's keeping me busy so I figure I might as well tap in to the experience of Stack :-)

I have a system that accepts measurement data from various sources. These data messages are put on a queue.
Now I need to build:

  1. A system to regularly read messages
    of that queue and persist the data
    within them to a database (probably
    a PHP script that is invoked by
    cron)
  2. A system to expose that data to external parties (implemented as an
    API/webservice)

However, the database scheme is bound to change, so I figure I'd try my hands at Doctrine to abstract that part.

Now, if I use two projects, I'll have to use Doctrine in both, with them both having objects that reflect the same tables in the database below. So if the db changes, I need to change the model of two projects. That feels wrong.

I can use one project, with one ORM, so that if there are changes I only have to change one layer. However, then I have both a script using that model, and a webservice, all in the same 'project'.

Thinking litteraly 'projects', as in Netbeans for example. I suppose I would make a 'model' folder with the Doctrine objects, a 'script' folder which is accessed by cron and an 'api' folder which is accessed by the webserver.

It feels weird that one project has different applications, but it also feels best to have only one ORM layer. What's the decent thing to do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

神爱温柔 2024-11-24 20:33:41

我认为当您将其视为两个独立的“项目”时,您只是以错误的方式思考它,尽管我知道您来自哪里。您的项目是导入传感器数据并提供一个接口来接收该数据,因此将它们放在一个“项目”下是有意义的。

至于模式更改和使用 ORM,我建议检查 MongoDB(或另一个 NoSQL DB,我偏向 Mongo,因为这就是我所知道的)。您可能仍然想使用 Doctrine 之类的东西,但因为它本质上是“无模式”的,所以您可以更灵活地使用其中的内容。我建议仍然使用 Doctrine,因为如果你管理得不好,它既可能是一种负债,也可能是一种资产(即,将日期插入整数字段,Mongo 不会关心......)

I think you're just thinking about it the wrong way when you think about it as two separate "projects", although I see where you're coming from. Your project is to import sensor data and provide an interface to receive that data, so it makes sense to have them under one "project".

As to the schema changing and using an ORM, I'd suggest checking out MongoDB (or another NoSQL DB, I'm biased towards Mongo because that's what I know). You'll still probably want to use something like Doctrine but because it's inherently "schema-less" you can be a bit more flexible with what you put into it. I suggest still using Doctrine because that can be a liability as well as an asset if you don't manage it well (ie, insert a date into an integer field and Mongo won't care...)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文