具有现有数据库和具有多个源的类与手动存储过程的实体框架

Question

New to Entity Framework and ORM, however possibly have a unique circumstance where we are thinking of somewhat refactoring how our application works.

Right now we are using an in-memory distributed cache architecture, basically as an in-memory database in a fairly inefficient and error prone manner, whereby synchronization with persistent data, and even objects within the cache are not consistent.

The thought is to somewhat go back to the core and either integrate some form of ORM like Entity Framework or to manually create stored procedures within SQL to bring in the data needed to create a complex class.

As an example, let's say we have a class of SomeDashboard that will have many properties that are set based on the Dashboard requested (stored in SQL), but then many lists of objects that are related to the Dashboard , such as Products or Reviews , etc. One could write a stored procedure that would utilize a single DB request that would pull back multiple result sets to create all of those lists and object values.

Would it be better to create the stored procedure to do that, or create multiple stored procedures to get the data in pieces (meaning more SQL calls), or to piggy-back off of Entity Framework to piece-mill all of the objects together?

Something that's going to be volatile, causing this to need to be rebuilt quite often; worried about scaling of the database with so many connections and so many requests per each time we build the object.

Perhaps this makes enough sense to give some form of direction; I know it's vague, at best.

The other part of the question related to Entity Framework, would be -- how hard is it to map everything to existing databases and classes?

From a high level... feeling like the integration of the in-memory distributed caching was not thought out very well and done in such a way as to "preemptively optimize" that it's causing more issues than resolving; so going back to the roots and using SQL heavily, and then integrating caching selectively where it could be needed, and when performance with SQL becomes a problem seems like the best idea.

Answer 1

About the first part of your question, you should use eager loading on Entity Framework and let it query the data for you. This is the prupose of using an OR/M: you focus on the application code while OR/M does the raw part of reading and writing data to a SQL data source.

Check this MSDN article: Loading Related Entities .

About...

The other part of the question related to Entity Framework, would be -- how hard is it to map everything to existing databases and classes

This has no definitive answer. It might depend on your database design. If your database was built with good relational design practices, usually an OR/M will be easier to configure against that database.