We are developing a application which should use Entity Framework and its an simple WCf Soap service (not Wcf data service). I am very confused now I have read these following posts but I don't understand where to go This question is almost the same but I have a restriction to use POCOs and try to avoid DTOs. Its not that big service. But the link which I mentioned ,in answer its written that if I try to send POCO classes on wire, there will be problem with serialization.
This post has implemented the solution which related to my problem but he did not mention anything related to serialization problem. He just changed the ProxyCreationEnabled =false which I found in many other articles as well.
But these posts are also little old, so what is the recommendation today. I have to post and get lot of Word/Excel/PDFs/Text files as well, so will it be OK to send POCO classes or it will be problem in serialization.
Thanks!
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.
Related
I am using MVC 5 Web API with Entity Framework 6 database first while i'm serializing my Object to JSON i faced a problems with Self referencing loops, i googled to identify the problem and i found many solutions so i'm wondering what is the best model ever?
I Found:
use [JsonIgnore] but i will need to add it every time i update the model form DB
Remove virtual from the collection
create new layer of Data Transfer Objects (DTO)
Use JsonSerializerSettings (Doesn't work with me since it generates "$id", "$ref")
I guess you know that the answer is "It depends" right? However in my experience I have come to the conclusion that more often than not we end up with DTO layer. It is useful for solving a myriad of problems of this kind while other solutions solve only this particular instance. In other occasions we had to flatten the object (Employee.CompanyName instead of Employee.Company.Name) and other similar issues. The downside is that you cannot directly expose IQueryable from your API although we did something to translate expression trees. So basically I guess it is a question of whether you care about the IQueryable exposed directly from the service.
I am building an application. I am creating a Silverlight 4 client with the help of MVVM Light. I am acquiring data from a WCF Service. At least, this is the plan.
In the WCF Service I have defined the "entities" that I need to use in my application. When in the Silverlight Client I add a reference to my WCF Service, Visual Studio recreates on the client-side all classes that were marked with the attribute [DataContract] in the service.
What I would like to know is if this is a bad practice and if it were better to create the Models inside the Client. As far as I understand, in the first case I should only create the ViewModels and the Views in the Silverlight client, whereas in the second case I should create the Views, ViewModels and Models inside the Silverlight client, and populate the Models instances with the values coming from the WCF Service.
Thank you for your help.
Cheers,
G.
UPDATE
Ok, I don't think my question was clear enough as I havent not received many feedbacks.
However, I'd like to provide an update on this. The answer I was looking for is "No! Data Transfer Objects!".
I was thinking to use my entity classes (the ones mapped to the DB tables) as DataContract in a WCF Service. Adding a reference to this WCF service in a client would have created all the classes decorated with DataContract on the client too.
The big problem in my case is that the data layer is based on Hibernate, which soemtimes makes extensive use at runtime of "data proxy" classes (see Castle Proxy). Well, it turned out that there is a serialization issue with these data proxies, and as far as I understood the best approach is to adopt the Data Transfer Objects pattern in order to map the "complex" entities to a similar but "lighter" class (the DTO).
I hope this can help someone else.
Have a nice day!
Gianluca.
Have you looked at WCF RIA with Nhibernate? To try and answer the question though: I wouldn't try and return entities from the WCF service directly, I personally would create DTO's. And then I would probably map those DTO's to some sort of a client side model. So, that's what I would try and do if I wasn't able to take advantage of RIA.
I'm starting a project using EF 4 and POCO.
What is the best practice for sending data to the client ? Should I send the POCO or I should have a DTO instead?
Are there any issue I should be aware of when sending the entity (that is disconnected from the context) to the client ?
Is it a recommended practice to send the POCO to the client layer?
I believe that we are mixing 2 definitions here that don't have relation with each other.
DTO or Data Transfer Object is a design pattern, you can use it to transfer data between layers, and also they don't have behavior. Martin Fowler explains this very well at: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
In the other hand we have POCO or Plain Old CLR Object. But to talk about POCO, we have to know where it started, that is POJO, or Plain Old Java Object. Martin Fowler with two partners coined the term and he explains it here: http://www.martinfowler.com/bliki/POJO.html
So POCOs can have behavior and everything you want. They are the same common classes you write in your daily-basis, they just gave them that name to call them in a short and easy-remember way.
In anwser to your second question, I think the best approach and the one I always go for is sending DTOs from the Busines Layer to everything that uses it (e.g.: your services, web site, desktop app, mobile app, etc.). This is because they don't have behavior and not pretty much than only properties in most of the cases, so they are light-weight and ideally to use in services, and of course, they don't reveal sensitive data from your business.
That being said, if you are planning to use DTO, I can recommend you to download EntitiesToDTOs, an Entity Framework DTO Generator that I just recently published at CodePlex, it is free and open source. Go to http://entitiestodtos.codeplex.com
For me, one of the main reasons to use EF4 with POCO is the fact that you don't need DTO's. I can understand using DTO's with traditional EDMX files where your entities are pretty bloated, but this isn't the case.
Your POCO obviously needs to be serializable, but there really shouldn't be any issues specific to sending POCO entities that don't also occur with DTO's.
I have a bit different opinion from above opinions.
I believe DTO or ViewModel is still needed for out side of the Server Layer.
In real world application, there is a few view layer which only need one Domain Object, that is, almost every views need multiple Domain Objects.
And all those Domain Objects are wrapped in one DTO or ViewModel Class.
This is why I insist DTO or ViewModel is still needed even though they are POCO.
I would consider EF4 entities business models AND viewmodels rolled into one. They already implement PropertyChanged out of the box, for example. Partial classes can provide custom functionality if you need. Mirroring the entities with your own safety layer creates unnecessary work and maintenance, in my opinion.
I'm a believer in separation of business logic and everything else. However in the case of EF4 the work is already done for you. Go nuts.
I'm curious to know what the community feels on this subject. I've recently come into the question with a NHibernate/WCF scenario(entities persisted at the service layer) and realized I may be going the wrong direction here.
My question is plainly, when using a persistent object graph(NHibernate, LINQ to SQL, etc) behind a web service(WCF in this scenario), do you prefer to send those entities over the wire? Or would you create a set of lighter DTO's(sans cyclic references) across?
DTOs. Use AutoMapper for object-to-object mapping
I've been in this scenario multiple times before and can speak from experience on both sides. Originally I was just serializing my entities and sending them as is. This worked fine from a functional standpoint but the more I looked into it the more I realized that I was sending more data than I needed to and I was losing the ability to vary the implementation on either side. In subsequent service applications I've taken to created DTOs whose only purpose is to get data to and from the web service.
Outside of any interop, having to think about all the fields that are being sent over the wire is very helpful (to me) to make sure I'm not sending data that isn't needed or worse, should not get down to the client.
As others have mentioned, AutoMapper is a great tool for entity to DTO mapping.
I've almost always created dtos to transfer over the wire and use richter entities on my server and client. On the client they'll have some common presentation logic while on the server they'll have business logic. Mapping between the dtos and the entities can be dumb but it needs to happen. Tools like AutoMapper help you.
If you're asking do I send serialized entities from a web service to the outside world? then the answer is definitely no, you're going to get minimal interoperability if you do that. DTOs help solve this problem by defining a set of 'objects' that can be instantiated in any language whether you're using C#, Java, Javascript or anything else.
I've always had problems sending nHibernate objects over the wire. Particularly if your using a ActiveRecord model. and/or if your object has ties to the session (yuck). Another nasty result is that nHibernate may try and load the object at the entry of the method (before you can get to it) which can also possibly cause problems.
So...getting the message here? problems, problems problems...DTO's all the way
I am working on a webservice where we use LINQ-to-SQL for our database abstraction. When clients use our webservice, the objects are serialized to XML and all is dandy.
Now we wish to develop our own client that uses the native data types since there's no reason to do objects->xml->objects. However, from what I understand you can't transfer LINQ objects as they directly map to the database and as such the data is "live".
My question is whether there is a way to take a "snapshot" of the data you've extracted, set the LINQ object to "offline" and then transfer it. The data will not be changing after it's transferred to our client and we don't need the database access.
The LINQ-to-SQL classes can be used with DataContractSerializer (for WCF) easily enough (you need to enable the serialization property in the designer, though). With this in place, you should be able to share the data assembly with the client. As long as you don't use the data-context, the objects themselves should be well behaved (just disconnected - so no lazy loading).
The trick is that you need to re-use these types (from the existing assembly) in your serialization code. If you are using WCF, you can do this with svcutil /r, or via the IDE.
That said though; it is often cleaner to maintain separate DTO classes for these scenarios. But I'm guilty of doing it the above way on occasion.
If you're willing to use WCF (for the webservice and the client) you can decorate your Linq2SQL generated classes with the [DataContract] and [DataMember] attributes.
Check the following links for some guidance:
http://msdn.microsoft.com/en-us/library/bb546184.aspx
http://msdn.microsoft.com/en-us/library/bb546185.aspx
http://www.codeproject.com/KB/WCF/LinqWcfService.aspx
http://www.aspfree.com/c/a/Windows-Scripting/Designing-WCF-DataContract-Classes-Using-the-LINQ-to-SQL-Designer/