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
Related
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.
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 am implementing a custom ASP.NET membership provider that operates based on the custom repository class that in turn uses an Entity Framework DbContext as a mean of accessing a data.
Since this is an ASP.NET MVC application, IoC container (Ninject) is set to resolve instances of my DbContext InRequestScope.
My user data tables are a part of the single main DbContext.
Repository class is also bound to instantiate in InRequestScope. But the repository class is created by to satisfy the need of the custom MembershipProvider, which can't be set to instantiate InRequestScope. As a result, whenever I am trying to access Role data via repository, I get DbContext is already disposed exception.
Has anyone set up a similar configuration and if so, what was implemented differently to overcome the problem I am having. Thanks.
A workaround that has allowed me to continue with the project development was to manually create an instance of DbContext in Membership Provider constructor, in contrast to have Ninject inject it.
Maybe someone eventually will come up with a better approach to this particular problem, please post it here and I will remark it as an answer instead of this workaround.
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'm checking out Linq for NHibernate 2.1 to use in an ASP.NET MVC application and I am trying to figure out session management. As a first experiment I am trying to modify the SportsStore application from Pro ASP.NET MVC Framework. This sample app uses Linq to Sql so I thought it would be a good exercise. I have NHibernate 2.1 accessing the database and non-Linq queries work fine.
In Linq to SQL we can create an IQueryable object from a data context and a connection string that can be passed around and used without worrrying about maintaining any context.
So for example, the original product repository code reads something like:
public IQueryable<Product> Products
{
get { (new DataContext(_connectionString)).GetTable<Product>();
}
and the app uses the returned IQueryable to populate product lists, retrieve product details, etc.
In NHibernate Linq similarly uses a data context but instead of a connection string, we supply a session object that has to remain in scope while the IQueryable is in use:
IQueryable<Product> products = new SportsStoreContext(session).Products;
So I'm wondering how I'm supposed to manage that session without doing too much violence to the structure of the sample application. Ideally I'd like a solution that would enable me to replace Linq to Sql code with NHibernate Linq by making only local changes.
An NHibernate session implements IDisposable, and most NHibernate samples demonstrate session management with a using{} construct but this strategy wouldn't work here. This thread discusses some different approaches, the S#arp Architecture and the HybridSessionBuilder. Is anyone using these for to replace Linq to Sql with NHibernate Linq? Are there other methods that would work better?
**EDIT
mausch has it right - the common way to approach this is with a httpmodule. NHibernate in Action describes two ways to do this: session-per-request (p334) and session-per-conversation (p340). The latter allows you to reuse persistent instances across multiple http requests. In addition to the links mausch provided, NHibernate in Action mentions NHibernate Burrow, Castle ActiveRecord, and Rhino Tools.
IMO the easiest way would be having a httpmodule that manages the session (session-per-request pattern) and then using dependency injection to supply the ISession to the controllers.
This is pretty much the approach used by S#arp and others.
LINQ for NHibernate builds on top of the "standard" NHibernate, so all session management patterns still apply.
Don't have the book though so I don't know how much would have to be changed...
Rhino Commons is a solution too. I use it in an ASP.NET MVC application works fine.