在 Symfony 2 和耦合中集成捆绑包(相关 Dotrine 2 实体)
据我了解,捆绑是分离功能。假设我有一个 UserBundle &一个BlogBundle
。然后我的 BlogBundle:Post
将有一个引用 UserBundle:User
的 author
字段。这不是违背了 Bundle 的目的吗?我无法交换另一个 UserBundle
吗?我怎样才能以正确的方式做到这一点?或者这是最好的结果吗?
As I understand, Bundles is to separate functionality. Suppose I have a UserBundle
& a BlogBundle
. Then my BlogBundle:Post
will have an author
field that references UserBundle:User
. Doesn't that defeats the purpose of Bundles? I cant swap another UserBundle
in? How can I do it a proper way? Or is this the best it can go?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您对捆绑包之间的这些依赖关系感到不舒服(我个人同意您的观点),您可以在任何捆绑包之外创建模型。可以这样配置……
ORM 的配置看起来很相似。
If you are uncomfortable with those dependencies between bundles (I personally agree with you), you can create your model outside of any bundle. This can be configured like so…
Configuration for the ORM would look similar.
捆绑包旨在尽可能地分离功能,但这并不意味着某些功能不会依赖于其他功能。
我认为有趣的是,即使是一些本应是独立库的 Symfony2 组件也具有依赖关系。例如,
HttpKernel
类依赖于HttpFoundation
和EventDispatcher
组件中的类。在您的示例中,如果您需要交换另一个
UserBundle
,则必须采取必要的步骤来确保您的BlogBundle
的依赖关系仍然得到满足。这可能意味着您需要重构。因此,捆绑包的目的并不会因为一个引用另一个而被破坏。即使捆绑包并不总是 100% 解耦,但使用捆绑包仍然具有优势。
Bundles are meant to separate functionality as much as possible, but that doesn't mean that some won't have dependencies on others.
I think it's interesting that even some of the Symfony2 components, which are supposed to be stand-alone libraries, have dependencies. For example, the
HttpKernel
class depends on classes from theHttpFoundation
andEventDispatcher
components.In your example, if you needed to swap in another
UserBundle
, you'd have to take the necessary steps to ensure yourBlogBundle
's dependency is still fulfilled. This may mean you need to refactor.So, the purpose of bundles isn't defeated because one references the other. Bundles are still advantageous to use even if they're not always 100% uncoupled.
好吧,在另一个应用程序的上下文中,人们可能不希望将给定的博客文章绑定到个人/用户,而不是组。为了使您的代码最大限度地可移植,我认为您应该稍微抽象一下场景。关系将是不可接受的。另一方面,所有者身份是。
想象一下给定的博客文章有一个所有者。在上下文中,如果不同的应用程序拥有自己的捆绑包,则所有者身份可能是组、用户、外部源等。
恕我直言,您应该仅使用撰写文章的“一个”的 id,而不是限制您的实现暗示这将是本地数据库中的一个“人”。
Well, in context of another application one might not want to bind a given blog post to a person/user, rather than a group. To keep your code portable to its maximum I think you should abstract the scenario a bit. Relations would be unacceptable. Owner identity, on the other hand, is.
So imagine that a given blog post has an owner. In the context if a different application with its own bundles, an owner identity might be a group, a user, an outside source, etc.
Imho you should use only id of the "one" who has wrote the article, not bounding your implementation implying that this would be a "person" on the local database.