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.
Related
I am sorry if I am asking something that has an obvious answer, but I have spent and entire day searching for resources on the subject and I fail to find or understand how to do a few basic thing with EF7.
So, here is my question.
I have an ASP MVC 5 (VNEXT) website and I am using Entity Framework 7. I have an existing database, thus I am working database-first.
So far everything was fine. I installed everything required to get my DNX EF commands up and working; I scaffolded a dbContext and I got all my tables as classes and a dbContext class.
Everything fine, all well. I was happy and continuing with my work.
However, I got to a point where I wanted to make a property of one of the generated (table) classes Required, because I use jQuery unobtrusive validation.
I have the following resource as a reference: http://ef.readthedocs.org/en/latest/modeling/required-optional.html
My first wonder is, according to this source, in the FluentAPI the property has been marked as .IsRequired(). I believe, making it required here is a whole other thing that has nothing to do with unobtrusive validation. So, the next thing explained is simply - go to your class and add the Required data annotation.
This is all fine and well, and after adding it, it works as it should.
But I immediately wondered - well, I am modifying the generated classes, am I not going to lose those changes once I update the model?
Which leads me to my final problem - I searched for a long time, I even played with the help menu of DNX EF, but I am unable to find the right way to update the dbContext and generated models after I make changes to the database.
I believed this to be something quite trivial but to my surprise I am unable to find a resource explaining how to do the update.
Can you point me in the right direction, and tell me how to update EF generated models and context after I make changes in the database schema, and what is the best way to add annotations to the properties of the generated classes?
The general consensus is that you shouldn't use your database entities as input from users directly. Instead, use ViewModels, verify those against your validation rules, then map them to database transactions.
As asp.net MVC developer I use database first and updating database is a big head ache so I use Metadata approach and create ViewModels which helps allot.
Having run into this issue:
Collection navigation properties may NOT be set
myself for exactly the same reason
and posting this suggestion on uservoice
https://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions/suggestions/3796779-repository-sample-that-serves-view-models-
After seeing the great new compact meta-data feature and reviewing the edmunds sample I am trying to put it all together and come up a solution that allows me to serve DTO's/View models versus full domain objects from a ef-codefirst web api back end and I have come up with two scenerios.
1)Use web api to return the DTO's/create the metadata in JS and use the where parameters to do filtering as required) thus as I understand it the entities can be tracked by breeze. The problem with this is that I will have to override save changes and convert dtos/viewmodels back to EF domain objects and save them. I am not certain that this is either as simple/ or as complex as I can see it being. Basically my proposed algorithm for this is to remove root objects and related children from the change set as DTOs and map them back to Domain objects which can then be added to the context and saved (seems like a lot of work and I am not totaly sure that the order this has to be done in is always knowable)
2) Follow Julie Lermans lead from the Pluralsight Enterprise EF couurse and create the partials directly in EF using code first and just let breeze work as designed. (in the course Julie creates stripped down models of Customer which have attributes placed on them that tells EF to map it to the customer table)
I would love to hear anyones thoughts on this. I am personally leaning towards #2 but I may yet be persuaded to choose #1 if there is a chance of a tool to generate the metadata from my C# clases or if the implementation of SaveChanges can be shown to be manageable and not turn into rewriting half of what EF is supposed to be doing for me)
I was looking into the same issue myself and I ended up going with option 2. For my situation, I felt that I had more control going with option 2 and that I was better able to map my data the way I wanted without feeling that I had more layers than my personal project needed. Julie Lermans "Shrink EF Models with DDD Bounded Contexts" (http://msdn.microsoft.com/en-us/magazine/jj883952.aspx) was a very helpful article for me as well.
Here is my knowing about ASP.NET SPA:
have to use Upshot to talk to the server;
have to use DbDataController to provide Web APIs;
have to use Entity Framework Code first...
so, many concerns come out:
have to provide metadata for the upshot to work, this will obviously expose the structure of your database;
can i use Entity Framework Database First instead of Code First? You may ask why. Because Code First don't provide you the ability to customize your database(index customization, stored procedure...etc.);
A problem i met: when i add a "TestUpshot.edmx" file(generated from database 'northwind') to the MySpaApp.Models folder(trying to test whether i can use the edmx classes in the MyDbDataController class, and generate proper metadata in the client side), and run the application, there is an exception:"System.ArgumentException: Could not find the conceptual model type for MySpaApp.Models.Categories."...
Need help here, thanks in advance.
Dean
I may be missing something, but there is no requirement to use any of the technologies you've listed.
An SPA is just a pattern. You can use whatever you need to achieve that. There may be benefits with choosing certain technologies, ie templates, tutorials, etc.
Doesn't really answer your question, but should lead you to experiment with what you've got.
SPA is actually a way to conceptualize your client application. SPA comes the closest to the fat client - data server concept from the current web approaches. Definitely this will be the ruling concept within a couple of years.
Your concerns can be addressed using JayData at http://jaydata.codeplex.com that provides advanced, high level data access for JavaScript against any kind of EntityFramework back-ends (db, model or code first). Check out this video that presents the whole cycle from importing your EDMX from SQL (this could eighter be model first definition as well) to inserting a new product item in the Products table from JavaScript.
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).
I wanted to know which would be best suitable - EDM or reflection provider for a project.
Definitely EDM is much simpler to develop over the database.But the problem is that,if we already have a data access layer over the database then we may have to change the existing architecture if chosen with EDM.So i wanted to know if there were any specific differences in using between entity data model or reflection provider to expose the data as Odata feed.
Reflection provider uses reflection to build model based on your class hierarchy. EDM provider uses directly the model created by the Entity Framework. If you have already a data access layer then I think you actually have three options:
- try using Reflection provider if it works great. Unfortunately I doubt it will work - it will change your objects but I don't think it will send queries to the database. In addition to be able to update data you will need to implement IUpdatable interface
- with EDM/EF provider you would probably need to move all you data access layer to EF. This means you would probably have to get rid of the access layer you have. The benefit is that once done it should work pretty much out of the box (queries updated etc)
- finally you can implement a custom provider. There is a few interfaces you would have to implement which would act as a bridge between the WCF Data Service and your access layer. Note that it is quite a lot of work. Here is the first post in the series that describes how to do it: http://blogs.msdn.com/b/alexj/archive/2010/01/07/data-service-providers-getting-started.aspx