title: Entity Framework with existing database and classes with multiple sources vs manual stored procedures
body: <p>New to Entity Framework and ORM, however possibly have a unique circumstance where we are thinking of somewhat refactoring how our application works.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>As an example, let's say we have a class of <code>SomeDashboard</code> that will have many properties that are set based on the <code>Dashboard</code> requested (stored in SQL), but then many lists of objects that are related to the <code>Dashboard</code>, such as <code>Products</code> or <code>Reviews</code>, 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.</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <p>Perhaps this makes enough sense to give some form of direction; I know it's vague, at best.</p>
  
  <p>The other part of the question related to Entity Framework, would be -- how hard is it to map everything to existing databases and classes?</p>
  
  <p>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.</p>