2016-11-30 4 views
0

クラス(PersistenceClass)があり、データの配列(posts)をとり、そのデータを解析してDBに入れます(doctrine経由)。フィールドcontentは、第2クラス(SyntaxClass)によって解析されてから、それがdoctrineエンティティに設定されている必要があります。はクラススコープを切り替える必要があります

今、問題は、SyntaxClassがコンテンツ内の参照を他の投稿(IDとのリンク)に設定する必要があることです。したがって、DBへのアクセスが必要であり、永続化されたがまだフラッシュされていないエンティティをPersistenceClassから検索する必要があります。

SyntaxClassに教義EMを挿入して、DBで私の参考文献を見つけることができますが、私はあまり好きではありません。しかし、より大きな問題は、唯一永続化されているが、フラッシュされていないエンティティにはどのようにアクセスできますか?PersistenceClass?私はそのオブジェクトの配列を作ることができ、以下のようなパーサメソッドにパラメータとして渡すことができます:

SyntaxClass->parseSyntax($content, $persistedObjects); 

しかし、それは非常にきれいに見えません。それ以外に、永続化されたオブジェクトのデータを検索することはどういうことか分かりません。

+0

[EntityManager#getUnitOfWork()]([documentation](http://docs.doctrine-project.org/projects/doctrine-orm/en)からUnitOfWorkの 'EntityManager#getUnitOfWork()'を見れば、 /latest/reference/working-with-objects.html#direct-access-to-a-unit-of-work)) – lolmx

答えて

1

あなたの質問にはサブ質問がたくさんあるので、まず最初にいくつかのことを明確にしようとします。

最初に使用した命名規則は少しばかりですが、これは将来、あなたのコードで動作するかもしれない他の人達に役立ちません。(おそらくあなたは成長し、より多くの開発者を雇う必要があります。だから、いくつかの命名法から始めましょう。

class PersistenceClass 
{ 
    public function parse(array $posts) 
    { 
     foreach ($posts as $post) { 
      // 1. Parse $post 
      // 2. Parse content with SyntaxClass 
      // 3. Persist $post in the database 
     } 
    } 
} 

同じことがSyntaxClassにも適用されます:それは$contentを受信して​​、いくつかの方法でそれを解析し、その後の参照を設定し、持続

何がPersistenceClassを呼び出していることは、このようなものかもしれません。

これは、境界線を設定するためのものです。

質問にお答えください。

私は非常にそれを好まないが、私は、SyntaxClassに教義EMを注入し、 DBの私の参照を見つけることができます。

これはまさにあなたがしなければならないことです! OOP開発はこのように機能します。

ただし、命名規則に問題があります。エンティティマネージャを挿入する方法は、クラスの構造によって異なります。

良いデザインはservicesを使用してください。

ので、現在、現実にはPersistenceClassSyntaxClassPersistenceServiceSyntaxServiceを(私は私のコードで私はいつもマネージャーやハンドラを区別するのでPersistenceManagerSyntaxManagerを、それらを呼び出すprefere場合にも呼ばれるべきものです - しかし、これは私の慣習です、私はここでそれについてもっと詳しく書きません)。

今、別の間違ったことをイメージしています(あなたの質問を読んで、私はイメージしています!):PersistenceService(現在はPersistenceClassという名前)からSyntaxService(現在はSyntaxClassという名前)というインスタンスを作成しています。これは間違っています。あなたは、各ポストのためSyntaxServiceの新鮮なインスタンスが必要な場合

は、その後、あなたはSyntaxServiceの新鮮なインスタンスを取得しますので、SyntaxFactory::create()を呼び出し、ファクトリクラス(たとえばSyntaxFactory)を使用する必要があります。新しく作成されたSyntaxClassにエンティティマネージャを注入するファクトリ自体です。

それぞれ新しいインスタンスを必要としない場合は、代わりにSyntaxClassをサービスとして宣言し、それを注射によってPersistenceServiceに渡します。この最後のシンプルな例下:

# app/config/service.yml 
services: 
    app.service.persistence: 
     class: ...\PersistenceService 
     # Pass the SyntaxInstance directly or a factory if you need one 
     aguments: ["@doctrine.orm.default_entity_manager", "@app.service.syntax"] 
    app.service.syntax: 
     class: ...\SyntaxService 
     aguments: ["@doctrine.orm.default_entity_manager"] 

しかし、より大きな問題は、私がどのようにアクセスすることができているだけ持続しますが、 はPersistenceClassからエンティティをフラッシュされませんか?

ここで2番目の質問:{persisted + flushed}と{persisted + not flushed}エンティティを検索する方法は?

問題は、フラッシュされる前に永続化されているがフラッシュされていないエンティティにフラッシュIDがないため、IDを検索パラメータとして使用できないことです。

解決策は別のサービスを作成することです:SearchReferencesService。その中でエンティティマネージャーも注入します(前述のように)。

このクラスには、検索を行うsearch()というメソッドがあります。 getScheduledEntityInsertions()getScheduledEntityUpdates()getScheduledEntityDeletions()getScheduledCollectionDeletions()getScheduledCollectionUpdates():エンティティを検索するに

が持続しますがフラッシュされない、UnitOfWorkはあなたにいくつかの興味深い方法を提供します。

あなたが話している配列はすでに存在しています。オブジェクトをオブジェクトごとに比較して、IDのもの以外のフィールド(検索されたフィールドはまだ存在しないため)に基づいて比較する必要があります。

残念ながら、検索の性質について詳しく説明していないので、この検索の仕方については正確には言えませんが、検索単位を使用して検索する必要があります最初の検索でnullの結果が返された場合は、データベースに接続して作業してください。また、この検索を(データベース内で、そして作業ユニットまたは副作業の前に)行う順序もあなた次第です。

希望すると、これが役立ちます。

+0

長い答えに感謝:)最初:はい、私はちょうど作られたので、非常にシンプルであいまいですここでの質問のために(私は実際のシステムの複雑さを打ち破りたい)。そして、はい、クラスはサービスです。そして、いいえ、私の意図と現在の流れは、構文クラスがデータを持続させているわけではありません。実際には、Syntaxクラスはヘルパーにすぎず、解析された文字列を返す1つのパブリック関数( 'parseString')しか提供しません。実際にはDBに接続するのが好きではありませんが、参照のために他の方法はありません。 – Asara

+1

しかし、参照検索のための新しいサービスを作り上げるというアイデアは良いものかもしれない、私はそれを再考すると思います。参照の検索は非常に複雑なので、私はすべての投稿を最初にフラッシュし、何らかの形で "まだ構文がない" – Asara

関連する問題