Are there any examples/articles on how to use the Entity Framework 4.0 Code First model (no edmx or xml configuration anywhere!!!) that interacts with stored procedures? Another aspect to my requirements is I am using a Repository pattern that uses an IRepository interface to abstract the actual data store (memory, database, xml, etc). Thus, I suppose it would be a hack to expose the ObjectContext so that I can call ExecuteFunction(...) on the ObjectContext instance since the caller of IRepository can never assume it is hitting a database. I was hoping to specify all stored procedure mapping logic in my mapping class for the entity. The mapping class is a subclass of EntityConfiguration. Is the 4.0 CTP mature enough for this yet?
I know it's a bit late now, but here is something worthwhile looking into: Entity Framework CTP5 - How to Call Stored Procedure? and Using stored procedures with Entity Framework 4 Code First CTP5. Did you manage with this?
Related
Let's say I am developing a few ASP.NET MVC applications working with data in an existing database just over by stored procedures, no and never linq to entities or anything else. That database contains lots of schemas and all my web applications needs the different schemas as well.
Here is my point:
I have a x.Model project in my solution that contains my ADO.NET Entity Model to create return types for all of my stored procedures in my existing db.
I have x.Repository.y projects in my solution where y is the schema name in the database. These projects contains classes having functions to call the stored procedures from the appropriate schema by ADO.NET Entity Model's context. So I have to have reference of x.Model in these repository projects.
And I have ASP.NET MVC projects that uses the necessary injected repositories from x.Repository.y projects. I use some of these return types of stored procedures as models in my views, so I need a reference to x.Model project too. But in that case this reference gives all the context to client web applications. I don't want my whole or partial db entities is reachable in my web applications. I just want them to know about necessary repository classes.
Is it possible? How can I do that?
If I remove x.Model project and create the ADO.NET Entity Models containing just the appropriate schemas stored procedures in my x.Repository.y projects then the referencing web applications again knows about this schema's whole db entities.
Thanks in advance,
Maybe, better way to use Model First or Code First approach. So, you can describe pure (without references to DbContext and other Data classes) entities. Then, create mapping in x.Repository project. And referene your Model to ASP.NET MVC site. So, you will have only entities and repositories but mapping and DbContext will be hidden inside one reference (you can mark mapping classes as internal).
I'm just now teaching myself MVC4 (did webform for years), and I'm
frustrated - but not about MVC which is pretty good. Entity Framework
is...well
I'm using VS2010.
The problem
We have a real database, you know normalized with like foreign keys and stuff. But every example I find for Entity Framework is direct to the table, but we rarely have a straight table pull - out side of populating dropdowns and such. All of our frontend calls hit a Stored Proc (how old school! expletive deleted)
I love the Model architecture of MVC where you define the attributes of the data coming from the data source - Display Name, Ranges, DataType. etc. So I definitely want to keep this.
Entity Framework and MVC do not want to play well in this senario. I created my edmx file (with SPs only), did my function import for a SP, everything is good....'til now.
Can't Create a Controller from the edmx/designer - Enter Controller Name, pick MVC controller with read using EF, pick the model class that is the FuntionName_Result, and for context pick the ...Entities name. FAIL Unable to retrieve metadata
OK, so now I try EF 5.x DbContext Generator, update the file name and boom I have a model and context - awesome now I can do the cool MVC stuff, lets rebuild the site....oh the horror - everything has been previously defined.
I tried generating the edmx in a different folder and/or deleting it after the DBContext generator, still can't create Controller.
'blah' is not part of the specified 'Context' class, and the 'Context' class could not be modifed to add a 'DbSet' property to it. (For example, the 'Context' class might be in a compiled assembly.)
IF I manually add the DBSet, I'm back to unable to retreive metadata - I am assuming this is happening because it can't connect to the DB. I don't know where to tell it to use the connection string in web.config. - if this is the problem
Here lies dead my MVC hopes of a brighter future.
What am I missing?
I am not married to EF, so if there is a better way to access databases (without writing all the code from scratch) I'm here to listen.
Thanks
Entity framework relies heavily on conventions. It takes a little bit to get used to. For example for connection strings... If entity framework doesn't find a connection string with the same name as your DBcontext class it just makes one (i think it defaults to using the project name as the database name). If this database doesn't exist it will create it locally as a sql express DB. This leads to the kinds of errors like the ones you are reporting.
If you want to define the connection string for entity framework all you need to do is provide a connection string in the web.config. Again conventions.... the connection string should be named the same as your DBContext class and entity framework will just find it.
<connectionStrings>
<add name="MyDbContextClassName" connectionString="..." />
</connectionStrings>
On an architecture note, IMHO ORM's are defiantly the way to go for new application development. It makes getting data into and out of your database soo much easier. That said it is a Big paradigm shift if you are used to accessing everything via sprocs and direct queries to the DB. Don't give up on it. It will frustrate you at first just like picking up any new tech, but it's well worth it in the end.
I have used entity framework and nHibernate for ORM in the past. The thing that I like about entity framework is that if you use code first migration most of the really annoying, tedious, and error prone column mappings are auto generated for you (again using conventions). You sometimes still end up having to do a little mapping but those cases are pretty rare. Maybe a little less rare if you already have a database since your column names will probably not always match entity frameworks conventions. Anyway... This is a big plus in my book and why I would defiantly favor EF over nHibernate.
If you already have a database, with stored procedures you do not need the EF 5.X DbContext Generator. Create either a folder in your project or a new project in your solution for your data access. In that folder/project add a edmx file and configure it to an existing database using the wizard. At this stage you can pull in your stored procedures.
If you open the edmx file, you can go to the model explorer tab and manage the imported functions (stored procs) and their return types.
Once you have that, In your controller, rather than using an instance of DbContext you can just use an instance of your EF Entities. So if you called your edmx 'MyDbAccess' you should be able to use MyDbAccessEntities which will then allow you to access the stored procedures.
I in your App.config file check your
<connectionStrings>
After check if your stored procedures are added in the model context file
YouDBModel.Context.tt
> YourBDModel.Context.cs
I need to use parameterized table-valued functions to retrieve the data for an association (the TVFs abstract the actual database tables), but would like to use all the good stuff provided by the EF. So looking at the generated Navigation Property code from the EDMX, I see that the RelationshipManager wraps the population etc. of the association.
So my question: can I retrieve the results I need from the DB (via the TVFs) and attach them to the context before the generated calls to the RelationshipManager, and also stop the RM itself from accessing the database?
EF4 does not support TVF. TVFs are available only in .NET 4.5 where you can use them in Linq-to-entities queries. .NET 4.5 also by default uses POCO entities which are now strongly recommended where RelationshipManager is not used inside the entity (except dynamic proxies for lazy loading).
I am quite new to entity frame work 4.0 and what I know from my intial analysis is entity framework is nothing but an abstraction of ado.net with its storage model, conceptual schema and the mappping between these two.But one thing I am unclear is while fetching data from database or executing any stored procedure what mechanism its following.
Is it adopting the traditional ado.net approach or is it the concept of linq2sql?
The reason I am asking this question is in our project we are not suppose to use linq for some security reason (I am not sure what this security linkage is but we have not to follow linq relegiously).
So I just wanted to know how entityframework works for performing all its db transaction and whether by any chance it is using linq to sql?
Hope I was able to convey my problem. Please look into this and respond ASAP. I am in a kind of fix :(
Regards
Subrat
No - both Linq-to-SQL and Entity Framework make good use of the LINQ features in C#/VB.NET - but they're both totally separate projects.
Linq-to-SQL was created by the C# team, more or less as a "proof-of-concept" for how to use LINQ with databases.
Entity Framework on the other hand grew out of the database teams (ADO.NET team) at Microsoft and was designed from the ground up as a full-fledged, enterprise-ready system to be the "next big thing" after straight up ADO.NET
Why using LINQ (as a technology) should have any security implications is beyond me.....
Yes - with the Linq-to-SQL approach, your application needs direct access to all underlying tables - read and write. But with EF in version 4, you can do very safe styles of work:
SELECT only from views exposed in the database
handle all the CUD operations (INSERT, UPDATE, DELETE) by wiring up your EF entities to stored procedures
With this, your applications don't need direct table read/write access at all - no different than when manually using SELECT from views and stored procedures for all other operations.
Although I believe I have a good grasp on MVC (from Rails), I'm learning the "MS Way" with ASP.NET MVC.
Also, I am learning Entity Framework as well.
I've created an Entity called User in my Models folder. Using LINQ to EF I can retrieve records and all is good.
Now, I want to put some business (or what I call, domain) logic in. But in my mind, EF is more of the DAL. So I created a folder called "Domain" and in there, I created a class for some business rules.
One of them is to encrypt passwords.
So I can use the following in my controllers:
string password = Domain.User.EncryptPassword(string salt, string password);
Also, that means the domain logic can access the EF User when it needs to persist to the DB.
Is this logic sound?
Any recommendations appreciated.
Thanks!
The only thing I would ask is: "Why would a user, a person, know how to encrypt or hash a password?"
Encrypting a password would be part of an Application layer. This is almost anti-DDD.
It depends a bit on the project, but generally we:
do not put any code in the EF models, all models are stored in a seperate project
place a business layer between the MVC code and EF. In previous versions of EF this would be used to map EF objects to domain objects, but with POCO this is no longer needed. Any caching would be done in this layer.
use a helper or utility class for encryption
I think what you are looking for is POCO (Plain Old CLR Objects). In one hand you have your EF entities. In the other hand you have your Domain or Business Entities... and then you can map them... your DAL Layer must return POCO entities and not EF entities.. at least that's how is made in a 3-tier application. I suppose it's the same approach in a MVC application...
Am I right?