My Question is about returning EF entity using WCF service. As wcf required Data Members for returning data. Solution i have to do mapping of entity to WCF data members which is quit hectic.
Is there possible solution which reduce my work effort. I tried EntityFramework with WCF - how to return EF entities but available solution have support for vs2010
only.
This is tricky question. You want to pass EF entities through WCF. This is bad in some way, because EF objects are burdened with additional data provided by EF (e.g. for change tracking purposes). The best way to pass objects through domains in your application is create DTO objects. To do that, you can develop additional mappings (with usage of T4 templates) that create this DTOs based on your existing EF entities.
Related
Using the Database-First EF model my DTO classes had a clear separation from the actual Database models created by EF. This provisioned a flexible architecture as the DTO and model weren't tightly coupled.
Using Code-First (which I've typically not used as often); I have come across a scenario where when I am adding a migration I get an error:
The Entity Type '[EntityTypeName]' requires a primary key to be defined.
The EntityType in this case is actually defined within one of my DTO classes and isn't intended to be the actual replica of any field in the corresponding Database model. It is a class created to facilitate Serialization data transfer of a JSON object from my API to the database.
But the real question is what concern or relevance is that of EF as it does not specifically relate to the underlying Database Model?
Is there something or someway I can alleviate the error to add my migration? Or is this a default behavior when using the .NET Core Code-First approach that can possibly be disabled? The build of the Solution is fine, it's just EF complaining.
I'm familiar with the EF and it looks pretty cool. As far as I can see, it is basically a LINQ to SQL with extra functions (like caching, automatic connection handling and so on). However, in my opinion EF is useful for those applications that directly comminicate with the model data (~persistence).
In case of writing a RESTful web service, we are reading and writing objects (for example) in JSON format. The application calls the web service with some data and it returns data back.
That's why I'm actually thinking on not using EF because it looks like an overkill for me. Since I'm not planning to expose the actual model, I would use DTOs instead (both as input and output of a web service call). This means that I have to do the mapping to the underlying model anyway so the EF would be used as a LINQ to SQL wrapper.
Is there anything I'm missing? Is there any feature that would be useful while writing a RESTful web service? is there any benefit from using EF instead of LINQ to SQL?
So the logic here is that you aren't exposing your entities past the data layer, so EF is pointless.
I never expose my EF Entities pass the business layer, just one layer down from the data layer. I always project them to ViewModels and Models which are just POCOs. I've seen this in lots of projects.
Rarely do I actually use the entity change tracking features. By the time a GET/POST has occurred it doesn't make sense to requery the entities on the POST just so you can update them via change tracking. Instead a direct update makes more sense and avoids an unnecessary roundtrip to the database.
My point being is in what I've seen it most commonly used, the EF models are not exposed past more than one layer in most cases. This ensures View/UI layers don't accidentally modify EF state or cause lazy loading(which is usually disabled).
However I still get to leverage the great EF/DB mapping layer and EF LINQ queries, which is by far the greatest features of EF.
Most alternatives such as Dapper are just that, a framework for executing queries.
So I wouldn't fallback to just doing ADO.NET or an older query technology just because you aren't using all the features of EF. You should still use a modern query framework such as EF or Dapper, simply because you are still executing queries. Just because you aren't exposing the entities doesn't change that.
All,
We are using EF as our primary data access technology. Like many apps out there, we have a business objects/domain layer. This layers talks to our repository, which, in turn, talks to EF.
My question is: What is the best mechanism for passing the data back and forth to/from EF? Should we use the EF-generated entity classes (we did DB-first development, so we have entity classes that EF generated), create our own DTOs, use JSON or something else?
Of course, I could make an argument for each of these, as well as a counter-argument against them. I'm looking for opinions based on experience building a non-trivial application using a layered architecture and EF.
Thanks,
John
I would use POCOs and use them with EF. You can still do that with the DB first approach.
The main benefit is that your business objects will not be tied to any data access technology.
Your underlying storage mechanism can, and will, change but your POCOs remain. All that business logic is easily re-used and tested.
As you're looking for cons, then I would say it might take longer. However, that cost is well worth it.
With t4 templates I put the actual EF generated entities in a common project that is referenced by all other projects. I use the EF database first created models through the entire application (including use as view models). If I need to add additional properties to an entity that are not in the database I just extend the partial class of the entity in the common project. I have written dozens and large nTier applications using this model and its worked great.
Ive been playing around with the entity framework with an idea for creating a web service to be consumed by an application in sharepoint that a 3rd party developer is creating. Basically i need to return a list of jobs e.g list based on some search criteria. I wanted to use the EF so i have something scalable however it seems returning POCO's from a web service is harder than i imagined it to be. Are web services and EF / POCO's meant to work together. Does anyone have any good examples or can point me to some.
Are web services and EF / POCO's meant to work together.
Yes. The only thing you must to ensure is to make your entities serializable - POCO entities can contain circular references which are not serializable by default.
What about consuming the web service? I read somewhere that the consumer has to reference the entity namespace to use the returned objects.
This is not true with POCOs. This is only true with Self tracking entities.
Given that directly exposing linq to sql or entity framework classes over web services is a bad idea, how should I expose the data over a web service such as WCF?
It seems like I would have to create a parallel set of classes for the web service, and then marshal the data into those, which doesn't seem very elegant.
The web services will be custom, so something like RIA is not very useful in this case.
You can use the support for POCO (Plain Old CLR Objects) in EF 4 to expose the entity model as simple objects. The designer supports converting entity data model into POCO objects.
Specifically for WCF service scenario, you could also use the self tracking entities T4 template available in EF 4 when you try to add new item to the project.
I hope following link will be helpful to you
http://blogs.msdn.com/b/efdesign/archive/2010/03/10/poco-template-code-generation-options.aspx
http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx
Generate POCO classes in different project to the project with Entity Framework model
Have you seen OData and WCF Data Services? Here is a great talk by ScottHa: http://www.hanselman.com/blog/ODataBasicsAtTheAZGroupsDayOfNETWithScottGu.aspx
OData, through WCF Data Services, works seamlessly with EF 4.