I'm working on a green-field application that has a corporate mandate that Stored Procedures are used for all database interaction.
I'd like to use Entity Framework and leverage Stored Procedure Mapping to gain the benefits of the ORM.
Since we will be developing the database and .NET application in parallel, I'm looking for information to help the database developer/administrator. Does anyone know of a consolidated guide on how to design tables and stored procedures so they can be best integrated with the Entity Framework?
A couple tips I've collected are:
Update Stored Procedures require exactly 1 parameter per table column
There must be an insert, update, and delete Stored Procedure for every table
I want to know as much about how the database should be designed for easy use with Entity Framework because the database is very difficult to change later in our environment.
I wrote a blog post describing the limitations of using mapping in this way after working on this for several months:
The Pitfalls of Mapping the Entity Framework to Stored Procedures
If you want to use Stored Procedures are used for all database interaction, I just don't see the need to use Entity Framework. One good reason of EF is to save time to write T-SQL, and if you don't take advantage of this, why even use EF?
Related
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
I am a DBA. I want to know what advantages my Business Objects developers will get when using EF with SQL Server DB which is fully managed using Foreign keys and Primarkey as and when require. As this is our new project and we have to use EF with SQL Server 2008 R2. We have a plan to use Database First Approach. Can anyone tell me what difference my Business Object developer will experience in case If I define all foreign Key relationships in my DB?
Assuming it's setup correctly, when your developers actually create their objects from the database structure, they'll be able to access any related tables rather easily.
It should also make creation of new objects (rows in the tables) easy, as it then shouldn't be possible to create new items that would break the foreign key relationship.
It's also just plain good practice to correctly setup any foreign keys in the database; I'm not sure of any benefit not to.
As a developer that's had to work with data sources that haven't been setup correctly, I can tell you a correctly setup database structure is an amazing experience for a developer.
(As an aside, as a DBA, you may want to take a look at EF. Also take a look at LINQ, one of the items that they'll be using. In particular, Why LINQ beats SQL may help you get a basic understanding, even if you don't agree with the article title :) )
Is it possible to use Entity Framework 4.3 without linking the model to an actual DB in the back-end?
I need to build a conceptual model of a database in the VS designer and then I'd like to manually handle fetches, inserts and updates to various back-end databases (horrible legacy systems). I need to be able to do this without EF moaning about not having tables mapped, etc. I realise that this is a very odd thing to want to do...
The reason for this is that we would like to move from these legacy systems into a well designed data model and .NET environment, but we need to still maintain functionality and backward compatibility with the old systems during development. We will then reach a stage where we can import the old data (coming from about 6 different databases) into a single DB that matches the EF model I'm building. In theory, we should then be able to switch over from the hacked up EF model to a proper EF model matching the new data structure.
Is this viable? Is it possible to use the EF interface, with LINQ without actually pointing it to a database?
I have managed to query the legacy systems by overriding the generated DbContext and exposing IQueryable properties which query the old systems. My big fight now is with actually updating the data.
If I am able to have EF track changes to entities, but not actually save those changes. I should be able to override the SaveChanges() method on the context to manually insert into various legacy tables.
I'm sort of at wits end with this issue at the moment.
UDPATE 4 Sept 2012: I've opted to use the EDMX file designer to build the data model and I generate the code by using T4. This enables me to then manually write mapping code to suit my needs. It also allows me to later perform a legacy data migration with relative ease.
If I were in your situation I'd setup the new DB server and link the legacy servers to it. Then create stored procedures to interface with EF for the INSERT/UPDATE/DELETE. This way your EF code remains separate from the legacy support messiness. As you decommission the legacy DB servers you can update your stored procedures accordingly. Once you have no more legacy DB servers you can either continue using your sprocs or do a refresh of your EF data connection to use the table schema directly.
Entity framework is to link entities to a data store without manual populates.
Otherwise you're just using classes with linq.
If you mean you don't want a seperate data store like sql server, mongo etc etc, then just let your application create the database as an mdb file that gets bundled in your app_data file. That means you don't need a databsae server so to speak and the database is part of your app.
If on the other hand you want a different way to save to the database, you can create your own data adapters to behave however you like. The mongo .net entity framework component is an example of this.
Alternatively, using code only you can just use stored procedures to persist to the database which can be a bit verbose and annoying with EF, but could bridge the gap for you you and allow you to build a good architecture with a model you want that gets translated into the crappy one in your repositories.
Then when the new database is ready, you can just rework your repo's to use savechanges and you're done.
This will of course only work with the code only approach.
At my client site the database user has permissions to execute stored procedures only.
Database user doesn’t have permissions to execute queries directly.
But I have used Entity Framework, and no stored procedures used.
What can I do?
In such scenario it is better to use native SQL + ADO.NET directly. The main power of EF is in mapping, linq / ESQL querying and loading strategies. Once you are limited to stored procedures you will lose support for latter two = no querying and no loading strategies. You will still have support for mapping but it will come with performance costs and it will demand strict limitations on your stored procedures.
The Entity Framework allows you to map each entity to a set of stored procedures that will execute the insert, delete and update.
That way the user won't have to execute queries directly when modifying the data in your database.
If the user also doesn't have Select permissions, you need stored procedures to access the data. The Entity Framework can help you because you can import Stored Procedures in the SSDL part of your EDMX and then you can map those stored procedures to functions on your ObjectContext.
I'm trying to display the results of a sproc in my MVC 3 web app.
However, the sproc calls into 4 tables on one database and joins them with 5 views (single table views only, thank goodness) on another database. Each (SQL Server) db is on a separate server but that shouldn't matter.
I've read this: http://blogs.msdn.com/b/swiss_dpe_team/archive/2008/02/04/linq-to-sql-returning-multiple-result-sets.aspx
and this:
http://www.codeproject.com/KB/dotnet/linqToSql5.aspx
and still cannot determine whether I should use the dataContext classes or just embed the straight SQL.
Perhaps there is a better way to return my results than LINQ to SQL (15 columns, 3 different data types)? I need to update the tables as well. The user will have the ability to update each value if they choose. Is this a task best suited for the entity framework classes?
I plan on using the repository pattern so I can change data access technology if I must but would rather make the correct decision the 1st go 'round.
I was hoping for a resource that was more up-to-date than say, NerdDinner and more robust than the movie apps for MVC3 that abound, particularly implementing the sproc results inside a view. Any suggestions would surely be appreciated. Thanks.
Once you plan to "update" data then you are going to handle it all through stored procedures. Both Linq-to-sql or Entity framework will not help you with this because they are not able to persist changes to something created from arbitrary query. You should very carefully check if you are even able to track the data back to the correct record in the correct table. Generally result of a stored procedure is mostly for viewing the data but once you want to modify the data you must work with each table directly or again use some stored procedure which will do the task. Working with tables from multiple databases can be pretty complex in entity framework (EF doesn't support objects from multiple databases in one entity model).
Also what you mean by 15 columns, 3 different data types? Stored procedures support in both Linq-to-sql and Entity framework will return enumeration of one flattened data type containing 15 properties.
I'm not aware of anything that linq-to-sql can do that Entity Framework can't really, so EF seems to be a better solution in this case. You can add a stored procedure to your Entity Framework model as well, so you can just have it call the procedure and deal with whatever comes back.
Since the end goal will involve accessing the same Databases with either technology and they will be using sql to retrive the data either way its really a subjective anwser.
I would use whatever technology you are most comfortable and focus more on the implementation. Both data access platforms are based off of ado.net technologies and are for the most part equally powerful.
Regardless of the technology I would evaluate how the data is accessed and make implementation decisions based on that.