Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have an upcoming requirement, and I'm unsure if EF is the right approach.
Essentially I have a Web Service Contract to implement, that has a handful of methods that return specific classes (DataContract classes with DataMember'd properties so they serialize correctly). The data that makes up the classes will be the result of queries against a backend database.
At the lowest level, I know I can just write some stored procs in the database that will return data rows that I can manually wire up to the custom classes, and call the stored procs from within a Data Layer class (calls stored procs, returns custom classes).
I'm wondering if I can use ADO.NET Entity Framework for this, however my understanding that this creates Entity classes from the database tables. My custom classes don't resemble any of the database tables. The stored procs perform aggregations and table joins to produce the classes.
Am I missing something here from what's possible with the EF? Or would I be better just going with stored procs / manually wiring up the custom classes in a data layer?
The Web Service will be hosted in SharePoint 2010 therefore I'm limited to ASP.NET 3.5. I think I'd be using Patterns and Practices to access the data layer, unless there are better ideas out there.
Given that you have indicated that you can only use .NET 3.5, you would be using EF 1.x which wasn't widely accepted in the ORM community.
EF 4.x is much improved, but unfortunately requires .NET 4.
DAAB is certainly an alternative, but you will still need to map out your Service entities from the data (i.e. DAAB isn't an ORM)
IMO EF comes into its own when used with LINQ, especially when used with queries - if you find that you are writing many SPROCs of the form GetXXXByYYY (or using lots of ad hoc or dynamic sp_executesql) to populate your entities, then a LINQ enabled ORM makes a lot of sense. However, if you only have a few heavy hitting PROCs which have well defined interfaces, then an ORM may be overkill.
If the object model of your application remarkably differs from the data model in your database then I'd stick to the classic ADO.Net + stored procedures for aggregations and table joins. My opinion is that any ORM brings more trouble than benefit in such case.
Related
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?
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.
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.
I am working on creating a service layer for a large sql server database (2008 R2) that is currently the backend for a winforms POS application with strongly typed datasets.
I think WCF is the way to go, and at first glance it seemed EF 4 was a good choice but now I'm having my doubts. Here is what I have found:
The stored procedure mapping isn't that great. I have hundreds of stored procs that I want to reuse. Most of them wouldn't return an 'entity' so the stored procs would have to be mapped to a complex type. Many of the procs use dynamic sql or temp tables so EF can't figure out what complex type to crete. Many of the procs return multiple result sets. I've read that EF extensions have a way to map stored procs with multiple result sets, but only for entities, so that doesn't help me.
Large models are a problem. There doesn't seem to be a good way to handle large entity models. The workaround of creating smaller models isn't that desirable and splitting the model loses design support, am I missing something?
EF mappings only go so far. The stored procs that I want to reuse return projections or information from many tables into a result set. There doesn't seem to be a way to map these results into entities, am I wrong? I've read about combining results from 2 table into 1 entity, but that only works if the tables have the same primary key.
Are people using EF in large scale existing databases? If not what would you recommend?
I've used EF on large scale databases, but as you say, the support for SPs as you have got is not great. That's not specifically a failing of EF per-se - ORMs in general work on the same principle and have the same "limitation".
If you have lots of SPs and are mapping them to datasets, you'll have to do lots of work even without SPs in terms of no longer referencing datasets and referencing your domain model types through your system, so you'd need to have some way to map your SPs to your domain model and back anyway.
For a new project, our application developers are wanting to use Entity Framework's table-per-type inheritance model.
We recently showed this functionality and the resulting table schema to our DBA, and he's expressed concerns, and I'm wondering how to address them. Inheritance is an important part of OO, and from a development side, it would be great to have the DB and ORM support this concept natively. This functionality is part of EF, so it's not like we're pulling the design out of left field.
His main concerns are:
We're not using stored procs
The added complexity will make reporting and data updates harder
We've pretty much addressed his stored proc concerns (and we've been using another ORM for 3 years now).
As far as the complexity, I do see his point, but the counterpoints address them (for me):
Reporting should not be performed from transactional tables (we currently do this), views or a transformed reporting DB should be used.
Data updates on a flatter structure can still mess up data -- it's the responsibility of the person updating the data to understand the structure. The schema used by EF's table-per-type inheritance model isn't that complex, but it must be adhered to when doing manual updates.
I know we're not the first to run into DBA concerns over DB-backed model inheritance. How have others convinced their DBA that this is a good model?
His main concerns are not considering real problems with TPT.
You can use stored procedures with TPT if you want.
Data updates are not harder. EF will deal with them and ensure correct order of data modification.
The main problem of TPT are inefficient queries (check comments as well). TPT in EF has real performance problems becuase it makes a lot of left joins and unions even if it doesn't need data from derived tables. Creating any reporting on this data structure and accessing report data through EF is really bad decision.
Edit:
If his concerns are related to other tools working with your database then they are fully legitimate but in the same time it is only about correct documentation of your database structure.