In our entity framework model that identify the customer, a simple Customer_GUID. We are using breeze with asp.net mvc and doing IQueryable.
Is there a way to globally not return those columns in the JSON? This would reduce a good bit of data coming across the wire. We don't want to remove it from mapping in our EF model because we still use it when we save.
You might want to look at the Json.NET documentation in particular the [JsonIgnore] attribute. Look at "Conditional Property Serialization" for more sophisticated scenarios.
Do be careful about insert and update data coming from the client. You'll have to do something if your client uploads a new entity for insertion and it lacks the properties you require on the server side.
To be clear, your configuration of Json.NET has no affect on your server-side EF model ... exactly what you wanted.
That also means that metadata generated from your EF model will describe properties the client can't see. You'll want to compensate for that I imagine. Such compensation is beyond the scope of this question; look to the Breeze documentation on metadata ... particularly "Metadata by hand" and "EF as a design tool".
Related
I just want to know how Entity Framework internally works to reveal properties and their types in runtime, particularly in case of Code-First approach, where there won't be system generated code. Can some body give some heads up? I don't think System.Reflection was being used implicitly?
Code first was first presented to developers as part of the EF Feature
CTP1 in June 2009 with the name “code only.” The basic premise behind
this variation of using the EF was that developers simply want to
define their domain classes and not bother with a physical model.
However, the EF runtime depends on that model’s XML to coerce queries
against the model into database queries and then the query results
from the database back into objects that are described by the model.
Without that metadata, the EF can’t do its job. But the metadata does
not need to be in a physical file. The EF reads those XML files once
during the application process, creates strongly typed metadata
objects based on that XML, and then does all of that interaction with
the in-memory XML.
Code first creates in-memory metadata objects, too. But instead of
creating it by reading XML files, it infers the metadata from the
domain classes (see Figure 1). It uses convention to do this and then
provides a means by which you can add additional configurations to
further refine the model.
ModelBuilder will now take this additional information into account as
it’s creating the in-memory model and working out the database schema.
By Julie Lerman
I am developing a SPA using Angular-Breeze-WebAPI-EntityFramework.
Now Breeze uses the Entity Framework metadata information to create it's own Breeze models. We use this in our application for Breeze validation.
So far, it's all been nice and easy. Now we are having to create a search page (say for querying customers). The search can be by Customer.Name or by Product.Id (which would return a list of customers who have bought that product). The result is a ng-repeater, which displays Customer.Name, Order.LastPlaced etc.
if you are getting confused by the tables and columns, forget that. What I am only trying to get to is that, both the search object and the result object are not 1:1 with Entity tables (or objects). So obviously I feel the need to create a custom object (one for the search and one for the results). My question primarily is where and how do I create that object?
If I create it at the data layer, Breeze would have no idea of the metadata for each of the properties (since it uses EF for that).
I obviously can't create just a JavaScript object, since I will have to query the database (using EF) to search and populate the object.
So where does one create such a custom object (traversing multiple tables) such that Breeze still can figure out the metadata and perform validation and such when the need arises?
Thank you all.
You can create metadata on the client for types that the server either doesn't know about or doesn't have the schema for. See http://www.breezejs.com/documentation/metadata-by-hand.
we have a very dynamic metamodel which changes frequently. We don't use EF but an own Database-Technology.
As we didn't find any good documentation on how the server-side metamodel has to be created "by hand", we decided to create the client-side metamodel and import this one into breeze when loading the application.
Now we have the problem, that eventhough we tell breeze to get all Person-Objects and take 3, the server expands all associations and returns more than 3 results. Breeze then cuts the result on the client to 3 and fills the properties.
Now I'm wondering, if we just didn't understand some of the concepts. All we want to do is to tell breeze dynamically how our metamodel looks like without using EF or NHybernate. Is there any documentation on that?
The only documentation on a Schema I found was this one:
http://www.breezejs.com/documentation/metadata-schema
But it only explains the client-Side-Metamodel but not the Schema that our Server-Side would have to generate. As far as I see it, the Server-Side-Metamodel gets translated into the client-Side-Metamodel anyways.
Would be nice if someone could clarify or provide a link with all the "basic information" about the topic.
The client metadata is for the Breeze client. The server shouldn't need it, because it already knows what the domain model looks like. The content of server-side metadata typically comes from the database and/or the mapping layer, when using an ORM.
Breeze's server-side WebApi filters attempt to apply the OData query parameters to the IQueryable that comes from the data provider (EF, NH, or whatever). If the data provider's LINQ implementation is incomplete, that could cause the problem you mentioned, in which take didn't work.
Unfortunately, the metadata-schema document is out-of-date. The structure of the Breeze metadata JSON format has changed since then. You are better off looking at an example of current metadata, and following the Metadata by Hand guidelines.
I'm planning on using the Entity Framework 4.1 in my next project, but I'm having trouble finding a good way to go about it.
In short, I want to build a multi-tiered application in which the entities will be travelling through web services, and to keep it all as clean as possible I want to use POCO's rather than self tracking entities. Also, there already exists a SQL 2008 database that will be used to base the entities on.
From what I've read so far (from Julie Lerman's article on http://msdn.microsoft.com/nl-nl/magazine/hh148150%28en-us%29.aspx, amongst others), it seems that:
If you use the Database First approach, you get a beautiful .edmx to edit your model in, but you'll always end up with persistence-aware objects rather than POCO's, which is not useful in my situation.
If you use the Code First approach, the "ADO.NET DbContext generator" only partially helps you: it does generate entities from the .edmx, but it doesn't generate the code required to get the foreign keys and cardinality correct. This means that the code will not work out-of-the-box (-edit, not true, see my post below-), you either have to
a) use Data Annotations on your POCO's, which is ugly imo because it pollutes the POCO's with database information and also creates a dependency on the EntityFramework assembly.
b) use the DbModelBuilder passed to DbContext.OnModelCreating to set the correct foreign key, mapping etc. information (i.e. the 'fluent' API). And even though the API may be 'fluent', it's still pretty hard (and probably unmaintainable) to set all this information correctly so that it matches the existing database (see http://sessionfactory.blogspot.com/2011/04/conventions-in-entity-framework-41.html for some examples of this).
I realize that the reason why the "DbModelBuilder-way" requires so much effort is because it was designed to be used the other way around: you're supposed to generate the database from the Entity definitions, not try to tweak all Entities so that they (hopefully) match an already existing database. However, it seems to me that the "DbModelBuilder-way" will, in the end, produce the best result: pure POCO's with no database metadata in them.
Now, having said all this, my question is:
Does anyone know of a way to load an .edmx into the DbModelBuilder, so that the foreign key, column mapping and other information doens't need to be specified by hand through the fluent API?
I think that this would be the best of both worlds, because you can visually edit the mapping like you would in the Database First scenario, and still get clean POCO's because all required metadata is stored in the DbModelBuilder.
Man what are you talking about?
If you use the Database First approach, you get a beautiful .edmx to
edit your model in, but you'll always end up with persistence-aware
objects rather than POCO's, which is not useful in my situation.
That is not true. EDMX can produce almost everything code first can and even many things which code first can't.
If you use the Code First approach, the "ADO.NET DbContext generator"
only partially helps you: it does generate entities from the .edmx,
but it doesn't generate the code required to get the foreign keys and
cardinality correct. This means that the code will not work
out-of-the-box, ...
That is not true. Once you set up EDMX correctly it will create exactly entities you want.
Does anyone know of a way to load an .edmx into the DbModelBuilder
That way is DbContext T4 generator!
Anyway there is one more tool you can check: EF Power Tools CTP1. This tool can create code first mapping from existing database.
Of course every tool creates model which is 1:1 mapping to the database. If you want anything more you must modify the model or mapping manually!
Apparently, there are two ways you can use the generated code from the "ADO.NET DbContext Generator", depending on which type of connection string you use.
If you use an entity connection string, i.e.:
<connectionStrings>
<add name="MyDBEntities" connectionString="metadata=res://*/Model1.csdl|res://*/Model1.ssdl|res://*/Model1.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.;Initial Catalog=MyDB;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
</connectionStrings>
the DbContext will be filled with all the metadata (column mappings, foreign key relations, etc.) from the .edmx. Also, the DbContext's OnModelCreating isn't executed. This is Database First using POCO's, and this is what I wanted to achieve.
What I did wrong was that I used a regular SQL connection string to pass into the DbContext. This causes a totally different type of behaviour: because the DbContext is now empty, it will try to explore all Entity classes and use conventions to generate a database schema for this. Now the OnModelCreating is called, expecting you to tweak this mapping and then generate a database from this.
In short, the solution was to use an entity connection string rather than a SQL connection string.
Read about the T4 POCO generation templates:
Walkthrough: POCO Template for the Entity Framework
POCO Template Code Generation Options
Using the POCO T4 Code Generation Template for Entity Data Models (video screencast with Julie Lerman)
Those T4 code generation templates allow you to use
database-first approach with EDMX model file
but: generate simple POCO (plain-old CLR objects) which have no inheritance from any EF specific class - they're just absolutely plain CLR classes.....
This gives you the best of both worlds - a nice EDMX model and persistence-ignorant POCO classes.
I was wondering what the general recommendation is for Entity Framework in terms of data validation. I am relatively new to EF, but it appears there are two main approaches to data validation.
The first is to create a partial class for the model, and then perform data validations and update a collection of rule violations. This is outlined at http://msdn.microsoft.com/en-us/library/cc716747.aspx
The other is to use data annotations and then have the annotations perform data validation. Scott Guthrie explains this on his blog at http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx.
I was wondering what the benefits are of one over the other. It seems the data annotations would be the preferred mechanism, especially as you move to RIA Services, but I want to ensure I am not missing something. Of course, nothing precludes using both of them together.
Thanks
John
I have been using DataAnnotations using MVC 2 and it works great. I have not tried the partial on an entity object for validation, but I see its uses. Basically if I create a partial class on an entity object I use it to default data such as a GUID identifier. or Create Date or modified Date. I guess it would be useful to add validations in the partial class perhaps for some complex validation that needs to happen in the entity layer but even then those validations could be accomplished in custom validator. If you are using an MVC website then I would personally use dataannotations.