I have a list of model classes, but I have only configured fewer classes in the metadata-only DbContext class, when it comes to generate metadata, it actually generates for all the classes, how does that happen, I couldn't work out, please help, thanks in advance and Merry Christmas!!
Breeze uses the DbContext's CSDL ( part of the EntityFramework MetadataWorkspace) to generate its metadata. So basically, the Entity Framework has performed reflection on your classes. The EF documentation should give more information.
Related
we've been using breeze for a long time and now I'm trying to access an existing webapi controller with a breezesharp client. Our controller is using NHibernate for data access.
On FetchMetadata the application throws an object reference not set exception on that line(24)
_schema = json["schema"]; in CsdlMetadataProcessor.
If I look at our metadata there is no schema node.
Am i missing something? Is there a different configuration for NHibernate?
edit: I also tried to export my metadata and import it with ImportMetadata on the metadatastore but it throws another exception when creating the clr type...
Thanks
Ok, this was a bug and will be fixed in the next version of breeze-sharp, out later this week.
Ok,
it's my fault. The bug with the NHibernate metadata has been fixed but my entities doesn't inherit from BaseEntity. We are heavily using breeze with a SPA and I was happy to reuse my existing code with a .net client but deriving my model entities from the BaseEntity class of Breeze is not an option.
Would it be possible to use reflection.emit or Castle DynamicProxy to create proxies of the model on the fly? That way the model could stay without any inheritance.
Thanks
I am trying to find a way to generate breeze metadata from poco's. It seem that hand writing js models is error prone and duplicates work. I cant put everything I have in EF. Some of the data I have is coming from a 3ed party web service. I would think there should me a function for this.
What is the correct way to do what I want.
It's a good question, and we've discussed creating a reflection metadata provider but haven't gotten further than that. Please add this to the Breeze User Voice. We take these suggestions very seriously.
Another, slightly hacky, approach is that you can use EF's CodeFirst annotations on your model without actually using EF for anything other than metadata creation. In fact, you only need to run the EF metadata creation logic once and cache this on the server in a file, so that you never need EF at runtime at all. The CodeFirst annotations are also not very intrusive and if Breeze were to implement a reflection provider, we would probably need to create similar annotations.
I have an ntier solution which has a Domain project for my POCO classes. I want to generate the database with some table fields constrianed to a particular length. Now I see two ways of doing this, either Data Annotations in the POCO classes themselves or using the OnModelCreating method in my DbContext but which is the best way?
My concerns with the OnModelCreating approach is that this is then specific to Entity Framework. Should I switch to another ORM, the database conguration is lost unless I re-implement it.
With the Annotations approach, I end up cluttering my models and worry they lose the "POCO" tag. I am also unsure if other ORMs would respect the Annotations. On the other hand, all the information about what the database should look like is tied to the model so easy to maintain.
Any thoughts to point me in the right direction?
OnModelCreating is better. Some mapping features are not available through data annotations. Moreover as you already mentioned in some cases data annotations goes against POCO principle because your classes can contain information about persistence and even some data annotations currently need EntityFramework.dll referenced in your domain project.
Also be aware that data annotations are MS specific feature used mostly by MS tools. If you want to use them with other ORM you will have to implement conversion from data annotations to ORM's mapping description (unless it already exists).
With EF 4.1 on the way and CTP5 being available for few months now I've decided to try out the new functionality. As I see, there are multiple generation items available (DbContext and three different ObjectContext's). I also noticed they are not interchangable - I was first using the POCO ObjectContext in one of my app and today switched to DbContext and my entire repository broke. It was based on LoadProperty() methods, DeleteObject() and AddObject() methods and those are all missing on DbSet class which is used in DbContext generation.
I know there's a great blog series here http://blogs.msdn.com/b/adonet/archive/2011/01/27/using-dbcontext-in-ef-feature-ctp5-part-1-introduction-and-model.aspx introducing the new functionality but it never really says when to choose what.
My requirements are:
ASP.NET MVC application, so lazy
loading mostly won't work coz at page
render it will say that context has
already been disposed (that's why I
need easy support for explicit
loading - in EF4 I did it via
Include(), using POCO context I did
it through LoadProperty() and now
in DbContext I believe I will use
the strongly typed Include()).
We probably won't be needing code-first
features (but you never know).
Difference between those two is mostly in API and feature set. DbContext of course have Include for query and Load but you will find it elsewhere. Moreover when using CTP5 assembly you will have strongy typed Include for both ObjectSet and DbSet (available on IQueryable interface as extension method).
Explicit loading (equivalent to LoadProperty) is performed by Load method on DbReferenceEntry<T> or DbCollectionEntry<T> - check Explicit loading related entities. It works even better then LoadProperty because you can define filter for loading.
You are starting with the wrong assumption that you can't use lazy load with MVC.
If you manage the context at a higher level, you'll be able to do that without problems.
I have read here 3 approaches towards implementing POCO with entity framework namely
Create edmx model and turn off code generation so the model will not create heavy entities for you. Then you will create your POCO classes which have to follow some restrictions.
You can use the POCO template which can be downloaded to VS 2010.
Use Code First approach where you code your POCOs and you define mapping in code. To do
this you need EF 4.0 Feature CTP from here.
I was personally going to opt for the second approach as it is quicker but what are the things that I should keep in mind since it derives from ObjectContext I guess it is in a way coupled? I know the third approach gives the most flexibility but is it worth it ? Please share your thoughts regarding this..Thanks!
That link you have provided for "POCO Template" is broken - but i assume you mean this:
http://visualstudiogallery.msdn.microsoft.com/23df0450-5677-4926-96cc-173d02752313
This template can (and should) be used in conjuction with Option 1 you have stated.
That's what i use in my current application:
1 - Create EDMX Model
2 - Turn off code gen
3 - Use POCO Generator to generate POCO classes
The POCO's do not derive from anything - they are pure POCO's.
I found these two links to be invaluable when setting up my model/poco classes. Poco generation and Poco options. As mentioned above it is a good idea (certainly if using the repository pattern) to turn off code generation in the edmx and create both a derived ObjectContext class and your Poco classes via the two T4 templates provided by Microsoft.
If you use the T4 templates without making any changes to them then you will get a set of Poco classes with the "Change Tracking Proxies with Fixup" option enabled in the generated code.