I remember this was a problem with previous version of EF. You couldnt make collections as IEnumerable for exposing your methods instead. This is a problem because i don't want someone to directly access the collection.
See this for more info on what i am talking about... Why does the entity framework need an ICollection for lazy loading?
So the question is.. are EF 4.1 now support IEnumerable property for mapping relationship ? or is there a solution to this ?
Thanks.
No it doesn't support IEnumerable because EF internally needs collection which can be assigned and filled by calling Add.
Related
I have an Object that is reference by two other Objects
I use Jackson to serialize my objects but have found my shared object is duplicated rather than reference.
The reason is as I understand that Jackson can only serialize by value and not by reference.
I have unsuccessfully looked around for some recommended solution.
Any and all help is appreciated.
current Jackson Lib 1.8.3
Well time passed and Jackson 2.0 is out. Here is the requested feature ! I answer this so people like me coming after know its available
https://github.com/FasterXML/jackson-docs/wiki/Presentation-Jackson-2.0
Currently (1.9) you would have to write custom serializer, deserializer, to handle this. There is no out-of-the-box support for handling object identity.
Of Java frameworks the only one that I know to support object identities is XStream.
For what it is worth, there is a long-standing feature request for Jackson to add support. And there is reasonable chance this gets worked on for 2.0. But even if it will be, it'll take a while (a month or two).
UPDATE (April 2013): As per the other accepted answer, this feature -- #JsonIdentityInfo -- was indeed included in Jackson 2.0, and is available. No need for custom (de)serializers.
I am mapping some pre-existing Business Objects to our database using Entity Framework. These object were originally using a home-grown data access method, but we wanted to try out Entity Framework on it now that it is using Code-First. It was my expectation that this would be fairly simple, but now I am having some doubts.
I am trying to use only attributes to accomplish this so that I don't have some of the mapping here, some of it there, and still more of it over there....
When I query for entities, I am getting System.Data.Entity.DynamicProxies.MyClass_23A498C7987EFFF2345908623DC45345 and similar objects back. These objects have the data from the associated record there as well as related objects (although those are DynamicProxies also).
What is happening here? Is something going wrong with my mapping? Why is it not bringing back MyBusinessObject.MyClass instead?
That has nothing to do with mapping. Those types you see are called dynamic proxies. EF at runtime derives class from every type you map and use it instead of your type. These classes has some additional internal logic inside overriden property setters and getters. The logic is needed for lazy loading and dynamic change tracking of attached entities.
This behaviour can be turned off in context instance:
context.Configuration.ProxyCreationEnabled = false;
Your navigation properties will not be loaded automatically once you do this and you will have to use eager loading (Include method in queries) or explicit loading.
The custom BeanSerializerFactory in http://kyrill007.livejournal.com/2577.html is the only custom solution I found to allow directly throwing persistent beans to JSON via Spring 3.0, and it works, it only serializes non initialized (lazy) attributes / collections (this allows me to use the entity Pojo as a DTO, as I initialize only what I want, and what is not initialized, doesn't get serialized to JSON)
But this worked well with Jackson 1.6, and I wanted to upgrade to Jackson 1.8 to solve the issue with Java Generics (hopefully) and now that custom solution is not compiling.
So my questions are
What is the recomended way to auto serialize Entities to JSON without the need of DTOs
Is there an official Hibernate Aware Jackson BeanSerializerFactory besides the above
I'm starting to fear that if it's that hard to find, maybe my practice is not the best one
What is the recommended way to do RESTful Ajax then with Spring 3.0 MVC and JSON?
The problems to solve are
Not serializing lazy attributes / collections automatially (as the custom code above does)
Supporting Java Generics and some kind of a client side object schema / validation
What works on get should work on save, and allow partial objects graphs to be returned safely
Is there Anything? do I have to manually write DTOs for every Entity?, this is so non productive
While SO has lots of experts, you might consider also asking on Jackson users list. Kirill (author of the blog entry) is responsive, and there are other experts there as well.
I've found that Linq2Sql doesn't (Rhino) mock well, as the interfaces I need aren't there. Does EF generate code that's more mockable?
NOTE: I'm not mocking, yet, without interfaces, the next reader of this question may not have my bias.
EDIT: VS2008 / 3.5 for now.
Entity Framework 1.0 is mockable: http://blogs.msdn.com/diego/archive/2008/03/03/unit-testing-your-entity-framework-domain-classes.aspx
It's not pretty, but it's possible. EF 4 is much improved over EF 1.0 in this regard.
I would think that if, for example, you have Data Access Objects (DAOs) over your Linq2SQL objects they can implement intefaces and therefore work well with RhinoMocks.
If I try to serialize a linq-to-sql entity, will it by default serialize only the primitive fields or will it try to access the relationship fields as well? If it tries to grab relationship fields, is there a way to override this?
Which serializer are you using?
The DataContractSerializer will
include loaded relationships but not
those that are not yet loaded / null.
The XmlSerializer tend to choke on relationships if they are bidirectional (i.e. entity A points to entity B which in turn points back).
The binaryformatter ... I never got that one to work properly with L2S entity objects having relationships to other entities. Long time since I tried though, so maybe I just did something wrong...
Another point to add to the accepted answer:
Relationships that are not collections will never be serialized by DataContractSerializer (whether they are loaded or not), because no DataMember attribute is generated for them from the .dbml file.
I found here an explanation by then-at-Microsoft Daniel Simmons:
The issue here is that prior to SP1 there was really no good way with DataContract serialization to handle graphs of objects that had cycles. As a result for LINQ to SQL the compromise decision was made to allow users to opt-in for uni-directional serialization and to only serialize collections not references. This mechanism doesn't work well for cases where you really want to serialize a reference (like your scenario above), but it at least gets you going for some common scenarios.
In SP1 new support was added to WCF which enables DataContract serialization to deal with cycles, but it is something you must opt-in to by changing some of your DataContract attributes and potentially also making changes to your collection and reference class implementations to properly handle the serializaiton and especially the deserialization behaviors of WCF. In the Entity Framework the changes were made to take advantage of these new features since it had not yet released its very first version, but Linq to SQL only had a small service-pack upgrade in sp1 and it was not modified to take advantage of this capability.
I have not experimented with this on L2S, but it might be possible to generate your own classes which work with L2S and have the right support for WCF serialization with cycles.
Danny