Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You've got the general idea, but it takes a while to really get used to Dependency Injection. I see a number of possible improvements to be made:</p> <ol> <li>Your <code>IServices</code> interface seems unnecessary. I'd prefer to have the controller specify which services it needs (IPhotoService, etc.) via its constructor, rather than using the <code>IServices</code> interface like some kind of strongly-typed service locator.</li> <li>Did I see a <code>DateTime.Now</code> in there? How are you going to verify that the date gets set correctly in a unit test? What if you decide to support multiple time zones later? How about using an injected date service to produce that <code>CreatedDate</code>?</li> <li>There is a very good Ninject extension specifically for MVC. It takes care of plugging into the various points that MVC 3 supports for injection. It implements things like your NinjectControllerFactory. All you have to do is make your <code>Global</code> class extend a specific Ninject-based application.</li> <li>I'd suggest using NinjectModules for setting your bindings, rather than setting them in your ControllerFactory.</li> <li>Consider using Binding by Convention so that you don't have to explicitly bind each service to its implementation.</li> </ol> <h3>Update</h3> <p>The Ninject MVC Extension can be found <a href="https://github.com/ninject/ninject.web.mvc">here</a>. See the README section for an example of how to extend the <code>NinjectHttpApplication</code>. This example uses Modules, which you can read more about <a href="https://github.com/ninject/ninject/wiki/Modules-and-the-Kernel">here</a>. (They're basically just a place to put your binding code so that you don't violate the Single Responsibility Principle.)</p> <p>Regarding conventions-based bindings, the general idea is to have your binding code scan the appropriate assemblies and automatically bind things like <code>IPhotoService</code> to <code>PhotoService</code> based on the naming convention. There is another extension <a href="https://github.com/ninject/ninject.extensions.conventions">here</a> to help with such things. With it, you can put code like this in your module:</p> <pre><code>Kernel.Scan(s =&gt; { s.From(assembly); s.BindWithDefaultConventions(); }); </code></pre> <p>The above code will auto-bind every class in the given assembly to any interface it implements that follows the "Default" conventions (e.g. <code>Bind&lt;IPhotoService&gt;().To&lt;PhotoService&gt;()</code>). </p> <h3>Update 2</h3> <p>Regarding using the same DbContext for an entire request, you can do something like this (using the <code>Ninject.Web.Common</code> library, which is required by the MVC extension):</p> <pre><code>Bind&lt;SiteContext&gt;().ToSelf().InRequestScope(); </code></pre> <p>Then any context-dependent services that Ninject creates will share the same instance across a request. Note that I have personally used shorter-lived contexts, so I don't know off the top of my head how you'd force the context to be disposed at the end of the request, but I'm sure it wouldn't be too difficult.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

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