Entity Framework とその単純な WCf Soap サービス (Wcf データ サービスではない) を使用するアプリケーションを開発しています。私は今、非常に混乱していますこれらの次の投稿を読みましたが、どこに行くべきかわかりませんこの質問はほとんど同じですが、POCO を使用する制限があり、DTO を回避しようとしています。それほど大きなサービスではありません。しかし、私が言及したリンクは、POCOクラスを有線で送信しようとすると、シリアライゼーションに問題があると書かれています。
この投稿は私の問題に関連する解決策を実装しましたが、シリアライゼーションの問題に関連することについては何も言及していません。彼は、他の多くの記事でも見つけた ProxyCreationEnabled =false を変更しました。
しかし、これらの投稿も少し古いので、今日の推奨事項は何ですか. Word/Excel/PDF/Textファイルも大量に投稿して取得しなければならないので、POCOクラスを送ってもいいのか、シリアライズに問題が生じるのか。
ありがとう！
I definitely do not agree with this answer. The answer mentioned suggests to reinvent the wheel (The answer does not even indicate why not using POCOs).
You can definitely go with POCOs, I see no reason to have serialization issues; but if you have any, you can write DTOs for these specific problematic parts and map them to POCOs in the Business layer.
It is a good practice to use POCOs as the name itself suggests; Plain Old CLR objects. Writing the same classes again instead of generating them will not have any advantage. You can simply test it.
UPDATE:
Lazy Loading: Lazy loading means fetching related objects from database whenever they are accessed. If you have already serialized and deserialized an entity (ex. you have sent the entity to client side over a wire), Lazy Loading will not work, since you will not have a proxy in the client side.
Proxy: Proxy class simply enables to communicate with DB (a very simple definition by the way). It is not possible to use an instance of Proxy in the client side; it does not make sense. Just seperate the Proxy class and POCO entities into two different DLLs and share only the POCO objects with the client. And use the proxy in the service side.