Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Creating a repository instance per request <strong>by itself</strong> shouldn't cause any performance issue; the repository is often pretty shallow, and when it needs to access data things like connection pooling minimise the cost of establishing actual connections. Object creation is astonishingly cheap, especially for short-lived things like web requests where the object gets collected while still in "generation zero".</p> <p>As to whether to have a single repository or a repository per instance - that depends on the repository ;-p</p> <p>The biggest question is: is your repository thread safe? If not: one per request.</p> <p>Even if it is though; if your repository <em>itself</em> keeps something like a LINQ-to-SQL <code>DataContext</code> (that you synchronize somehow), then you have big problems if you keep this long-term, in particular with the identity manager. You'll quickly use a lot of memory <em>and</em> get stale results. Far form ideal.</p> <p>With a single repository instance, you will probably also end up with a lot of blocking trying to get thread safety. This can <strong>reduce</strong> throughput. Conversely, the database itself has good ways of achieving granular locks - which is particularly useful when you consider that often, concurrent requests will be looking at separate tables etc - so no blocking at the database layer. This would be <em>very</em> hard to do just at the repository layer - so you'd probably have to synchronize the entire "fetch" - very bad.</p> <p>IMO, one per request is fine in most cases. If you want to cache data, do it separately - i.e. not <em>directly</em> on the repository instance.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload