This question is an extension of another question, but I think it warrants its own thread. See See Silverlight Question
I have a stored procedure (SQL 2005) that returns a dynamic data set (different columns/schema) each time it is called.
I want to consume this in Silverlight 3.0 so I need to somehow wire this up using Entity Framework and RIA Services. I also need this to be Bindable (Silverlight Grid) so I need these dynamic columns to be accessible via properties (grid limitation). Any ideas?
In the currently shipping version of the Entity Framework, the only type of stored procedures you can map are those which return entity types. The mapping is done, generally, before you compile, although it seems at least theoretically possible to generate Entity Framework metadata at runtime.
Therefore, I see a few choices.
Give up on the whole idea of consuming a procedure which does not return a defined schema. You will never be able to map such a procedure before you compile.
Dynamically generate EDMX at runtime in order to map an entity type to the expected output columns of the procedure before you invoke. Note that the current version of the Entity Framework is a bit finicky about the columns a procedure returns; you can find documentation about this on MSDN.
In .NET 4.0, there are new features which allow you to inform the Entity Framework about your client schema at runtime without having to generate EDMX first. You might be able to leverage these features in order to map some entity type to the expected output columns of the procedure.
Again, in .NET 4.0, there may be support for procs which return scalar values. I can't remember if this is the case or not.
You can always get a standard database connection from the entity connection and execute the procedure directly, using regular SqlCommands. Unfortunately, this makes your code database-provider-specific, but it may be the simplest solution to your problem. Indeed, using such a procedure at all is already database-server-specific.
You might use a WCF web service wraper for accesing your SP and use the WCF service as data source Brad Abrams has a way to do that on his series of articles on RIA Services
Related
How to create View (SQL) from Entity Framework in ABP Framework
Not allowed to post comments because of reputation. Just trying to get more information on connecting a database to an Entity Framework, without having to switch to a code-first development style. View selected answer's response (he told the OP to basically do the same thing he was going to do in the DB but with EF, and then added an extra step where EF "...ignores..." the previous instructions...
I want to create tables and design database directly in SQL, and have the csharp library just read/write the table values (kind of like how dapper function where it isnt replacing your database, just working along side of it).
The tutorials don't talk about how to integrate your databases with your project. It either brushes over the subject, ignores it completely, or discusses how to replace it.
I don't want to do any EF migrations (i dont want/need to destroy/create database everytime i decide to run, duplicate, or transfer project). Any and all database back-track (back-up/restore) should be done with and thru SQL (within my work environment).
Just to be clear on exactly what i'm trying to learn:
How does somebody who specializes in database administration (building database schema, managing and monitoring data, and has existing database with data established) connect to project to fetch data (again, specifically referencing Dapper's Query functionality).
I want to integrate and design micro-services, some may share the same database connection or rely on another. But i just simply want to read data in a clean strongly-typed class entity, and maybe deal with insert/update somewhere else if i have to.
I would prefer to use Dapper instead of EF, but ABP is so heavily integrated with EF's design, it's more of a headache to avoid it, than it is to just go along with.
You should be able to map EF under ABP the same way as any other project using DB-first configuration.
The consistent approach I use for EF: (DB-First)
Define entities to match the table/view structure.
Define configuration classes extending EntityTypeConfiguration<TEntity> with the associated ToTable(), HasKey(), and any HasMany/HasRequired/HasOptional for relationships as needed.
In DbContext.OnModelCreating: modelBuilder.Configurations.AddFromAssembly(GetType().Assembly); to load all entity configurations. (assuming DbContext is in the same assembly as the models/configurations Substitute GetType().Assembly to point at the entity assembly.
Turn off Migrations. In DbContext constructor: Database.SetInitializer<MyDbContext>(null);
EF offers a lot more than simply mapping tables to classes. By mapping relationships between entities, EF can help generate optimized queries for retrieving data across those related entities. This can allow you to flatten data structures without returning unnecessary data, replace the need for views, and generally reduce the amount of data coming across the wire from the database to the application server.
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
How to implement in EF5 a KeyTable style identity method
"Uses a table in the database to store the next Id, and advances this value every time a new block of Ids is required" from LightSpeed
I believe this is like Oracle sequences.
This feels like it should be easy (as it is in LightSpeed). This gives the ORM an easy way to do bulk inserts ie it can get 10 identities at a time, then do a bulk insert back to the db.
Am using EF5 / WCF RIA Services (latest) talking to Silverlight. The rest of the project uses bulk insert SSIS stuff.. and the SL project does some inserting. So I need to follow this convention.
I guess the question is fundamentally more about whether Entity Framework can support this style of key generation, and a secondary part of the question is whether RIA Services would integrate OK with that.
It reminds me of the range of key generation strategies that are available in NHibernate.
Here's an answer here which suggests that EF does not have such full support as NHibernate 'out of the box':
Unfortunately, EF doesn't have anything very close to the POID
generators like NHibernate does, although I hear rumors that similar
capabilities will be included in the next release of EF.
from HiLO for the Entity Framework
This answer suggests that it's not too tricky to intercept a Save (specifically an insert) in RIA Services and call a SPROC to get the new ID
you only need to call stored procedure to get a value before you are
going to save the record [can put this into an] overriden
SaveChanges() in your context
see https://stackoverflow.com/a/5924487/5351 in answer to What is the best way to manually generate Primary Keys in Entity Framework 4.1 Code First
and a similar answer here... https://stackoverflow.com/a/5277642/5351
Here are some findings on possibly implementing a HiLo generator (a more robust key gen pattern) with EF:
The Hi/Lo pattern describe a mechanism for generating safe-ids on the
client side rather than the database. Safe in this context means
without collisions. This pattern is interesting for three reasons:
It doesn’t break the Unit of Work pattern (check this link and this other one)
It doesn’t need many round-trips as the Sequence generator in other DBMS.
It generates human readable identifier unlike to GUID techniques.
from http://joseoncode.com/2011/03/23/hilo-for-entityframework/
I am having trouble getting related entities to be loaded on the client using RIA Services and EF 4.1 with Silverlight.
I'm currently using the Include() method on my DbDomainService with an Expression parameter and am finding that when stepping through my service the related entities are loaded just fine. However, when the Queryable results are returned to the client NO related entities are loaded - they are null. All of my entities are marked with the [DataMember] attribute so I have assumed that it isn't a serialization issue. Moreover, my DbDomainService query method is marked with the [Query] attribute.
I was wondering if there is anything specific that has to be set up on the client when using RIA Services with EF 4.1 code first? I must be missing something, but I'm not sure what.
Any help would be appreciated.
Thanks,
sfx
While you may have used the .Include() in your service call, you also have to add the [Include] attribute in the metadata class that is also created.
The .Include() statement tells EF to generate the SQL necessary to retrieve the data, while the Include attribute tells WCF RIA Services to make sure the Entity Class is also created on the client.
Once the data arrives at the client, it needs to know what type of structure to put it in as well.
HTH
In LINQ2SQL it was possible to set the return type of a stored procedure to auto generated.
I am unable to do so with the Entity Framework.
I want to set the return type of a stored procdure to auto-generated with the Entity Framework.
Is this possible?
Kind regards.
Entity Framework V1 has good support for working with Stored Procedures directly with entities (as Insert/Update/Delete operations) but as you have discovered, out of the box the support for SPs as functions on your ObjectContext is poor. They pretty much always have to map perfectly to an existing entity in your model as the expectation was you would then do changes to the returned results from the SP and hence would want to work with them as entities. Clearly this is not always the case.
Thankfully there are extensions for EF v1 which include improved support for SPs. Download the extensions here.
EF v2 will have better support.