locked
WCF Self Tracking Entities and JSON RRS feed

  • Question

  • I want to return JSON from a WCF service with Entity Framework 4.1 on the backend.

    I have tried several things but I can't get an object to serialize.

    Now I am trying to use Self Tracking Entities since that seems the most appropriate and I want to serialize an entity to JSON to a client which will consume it with Jquery.

            [WebGet(ResponseFormat = WebMessageFormat.Json, UriTemplate = "suspect")]
            public Suspect GetSuspect()
            {
    
                return new Suspect()
                 {
                    SuspectID = 1,
                    LName="test"
                 };
            }
    

    This is my test method above. I get this error from tracing  " cannot be serialized to JSON because its IsReference setting is 'True'. "

    I went to the generated Suspect class and set the IsReference to false but I still get the same error.

    Thursday, September 8, 2011 2:04 PM

Answers

  • Self-tracking entities work fine if both client and service are .NET, and if you're fine with the architecture where presentation layer is tightly coupled with data access layer. You can actually find a lot of scenarios where such a simple architecture works (especially when you build small tools). But SOA exists for a reason (well, actually a lot of reasons).

    One important feature SOA promises is interop. There're so many technlogies: .NET/XAML, HTML/JavaScript, native C++, and so on (by the way, you can use all of them on Windows 8). To create a service that is usable for all clients, you must not share implementation details and data types with clients. You can only share contracts. The contracts must be designed in a way that is understandable by all clients, such as XML or JSON. Entity tracking is service implementation detail, which must be hidden inside your service.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    • Proposed as answer by Yi-Lun Luo Wednesday, September 14, 2011 7:59 AM
    • Marked as answer by forwheeler Wednesday, September 14, 2011 12:56 PM
    Wednesday, September 14, 2011 1:50 AM

All replies

  • Hello, except for very simple scnarios, it is recommanded to design your own domain classes instead of exposing EF classes in the services. Make sure you don't set IsReference to true on the domain class if you want to use JSON.
    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    Friday, September 9, 2011 3:17 AM
  • I thought that was the purpose of sef tracking entities. You could serialize an entity framework and put it together on the other end.

    Would RIA services work for this scenario?

    • Edited by forwheeler Monday, September 12, 2011 4:22 PM
    Monday, September 12, 2011 4:09 PM
  • Why do you want to use self-tracking together with JSON? Self-tracking requires both client and service to be .NET applications. But JSON is usually used in AJAX. If you want to use self-tracking, you're essentially using traditional N-tire architecture, rather than SOA. You must share types instead of contracts, otherwise self-tracking won't work. This breaks one of the fundemental rules of SOA.

    Self-tracking should only be used if you don't need SOA, don't need interop with non-.NET technologies, and don't need to consider those features in the future. Actually it may even not work fine in traditional N-tire architecture, since the presentation layer will have to be tightly coupled to the data access layer (because they share entity types).

    Without self-tracking, it is still quite easy to use methods such as AddObject/Attach to maually perform data accessing. You're required to write more code, but you get a better architecture.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    Tuesday, September 13, 2011 3:00 AM
  • I guess that shows my ignorance. This is the first time I want to use JSON and to comsume it on the client using Jquery ajax. I thought that I could use EF and WCF to serialize the EF objects and present them on the client. Then I would be able to update them and then send them back to the server.

    Apparently this is the wrong way to do things since I can't find a best practice for this.

    This is really an architecture question for me. I am tring to find the best practice for intermitantly connected clients and using EF on the server side since that is what I am used to when creating ASP.Net applications.

    Tuesday, September 13, 2011 7:24 PM
  • Self-tracking entities work fine if both client and service are .NET, and if you're fine with the architecture where presentation layer is tightly coupled with data access layer. You can actually find a lot of scenarios where such a simple architecture works (especially when you build small tools). But SOA exists for a reason (well, actually a lot of reasons).

    One important feature SOA promises is interop. There're so many technlogies: .NET/XAML, HTML/JavaScript, native C++, and so on (by the way, you can use all of them on Windows 8). To create a service that is usable for all clients, you must not share implementation details and data types with clients. You can only share contracts. The contracts must be designed in a way that is understandable by all clients, such as XML or JSON. Entity tracking is service implementation detail, which must be hidden inside your service.


    Lante, shanaolanxing This posting is provided "AS IS" with no warranties, and confers no rights.
    Windows Azure Technical Forum Support Team Blog
    • Proposed as answer by Yi-Lun Luo Wednesday, September 14, 2011 7:59 AM
    • Marked as answer by forwheeler Wednesday, September 14, 2011 12:56 PM
    Wednesday, September 14, 2011 1:50 AM