Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When doing Dependency Injection the trick is to have all your classes inject their dependencies through the constructor. This way you can let the Kernel build up a complete object graph for you from the root object.</p> <p>This 'root object' however, is something that has to be resolved directly by calling <code>kernel.Get&lt;HomeController&gt;()</code> (if <code>HomeController</code> is the root object). So somewhere in your application you will have to call <code>kernel.Get</code>. It's impossible to go without.</p> <p>The trick is to minimize this to ideally a single line of code in the application and place this near the startup path. Probably close to the place where you registered your dependencies. The rest of the application stays oblivious to the use of any DI framework.</p> <p>There are even integration packages for Ninject and other containers that allow you to remove that single line of code depending on which application platform you use. ASP.NET MVC for instance has great extendibility points that allow you to plug in a <code>ControllerFactory</code> that allows you to let that factory call <code>kernel.Get</code> for you.</p> <blockquote> <p>How do we use DI without coupling to a DI framework?</p> </blockquote> <p>There will always be some coupling, but ideally this should only be the startup path. All other code should be oblivious to the use of a container. There will still be a assembly dependency, but this dependency will only exist in the startup project, and not in your business layer.</p> <blockquote> <p>look at the reason DI frameworks exists: To prevent having to do DI by hand</p> </blockquote> <p>To be more precise. DI helps making your application more maintainable. DI frameworks help making the startup path of your application (a.k.a. <a href="http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx" rel="nofollow">composition root</a>) more maintainable.</p>
    singulars
    1. This table or related slice is empty.
    1. POCoupling to Dependency Injection Frameworks
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSteven
    1. USSteven
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCoupling to Dependency Injection Frameworks
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI do like this approach, limiting dependency injection to an 'entry point' if you will. And since I use MVC this is even more appealing. However I do foresee a caveat, that being the entry point of the DI could become unnecessarily large. Furthermore this seems to be similar to just doing it by hand.
      singulars
      1. PO
      1. USMrJD
    2. COIf your entry point becomes "unnecessarily large" you might have to take a good look at your DI configuration and the application design. Take a look at things like batch registration (perhaps with convention based configuration). This lowers the amount of code (and increases the maintainability) dramatically. It's hard to define "doing things by hand" since even without a DI container, you would probably write LINQ queries and easy helper methods to keep this place more maintainable. Post any questions here on SO and get a copy of the book "Dependency Injection in .NET". It's a life changer.
      singulars
      1. PO
      1. USSteven
    3. COI can't recall my DI configuration to have ever become bigger than about a 100 lines of code for the biggest applications I dealt with. If you find yourself constantly changing this configuration, for the smallest changes in your application, again, take a good look at the design. There are things btw that are very hard to achieve by hand. Take for instance the proposed application design in [this article](http://bit.ly/s7tGEH) and the shown use of decorators. That's pretty awkward and maintenance heavy to do by hand.
      singulars
      1. PO
      1. USSteven
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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