Entity Framework performance issues

I'm having a problem with performance with the entity framework.

Here's the scenario.

I have an entity called "Segment". Each of these are stored in their own table in the DB.

"Segments" have a custom property called "IsHPMSSegment" which is a calculated field. It is calculated by calling a stored procedure in the DB that takes the "ID" of the "Segment" and compares some of it's value against values in another table.

One of the queries we need to run is stated as follows: Get me all Segments that are HPMS Segments.

Since the "ISHPMSSegment" value of "Segment" is a custom property, I cannot retrieve it's value directly from the DB when the segments are first selected. Instead, as each "Segment" is being created in the result set, entity framework queries the db again to get the value for "IsHPMSSegment". So everytime a "Segment" is being filled, it has to query the DB once again for each Segment returned.

Example: If I get all "Segments" with an ID greater than 5, and the resultset is 1000 segments, then the DB is hit for a total of 1001 times. Once for the initial select query that gets the 1000 records, and then another 1000 times to fill the "IsHPMSSegment" value of each of the "Segments".

The only workaround I can think of it to create a view in the DB ("vSegments") that contains this extra calculated property, and then link my EF object to this view, instead of to the "Segment" table. That way this property would be filled in the first query.

I then have two choices for the remaining functionality (insert, update, delete): 1) wire up my insert, update, and delete functions for the entity to stored procedures 2) make the view updatable

All of this seems like a lot of extra work just to address this performance issue, and I'm left wondering what benefit there is to using EF at all?

Is there a better solution to the "view + stored procedures" idea I stated above (still using EF)?

If not, what benefit does EF provide me? If I was creating my own DAL from scratch, I would still have to create stored procedures and/or views. How much effort am I really saving by using EF and having to program around it's limitations?

On top of all this, EF doesn't seem to handle updating multiple records at once in a satisfactory way. It sends a single update statement call for each record开发者_StackOverflow中文版 you are updating, even if you are updating them all exactly the same. This also seems to be a detractor (unless there is some workaround for this that I am unaware of).

---

This is entirely subjective. In my option the separation of duties between your layers is getting mixed up and causing you problems. My suggestion would be to remove your stored procedure and move the logic into you business layer. Creation of your 'segments' should start in your business layer and have all the appropriate logic done against it. The final state can then be pushed into your data access layer for persistence.