Stand up Ninject on MVC against EF4

Here's the bindings I used to get it done

    /// <summary>
    
    /// Load your modules or register your 
services here
    
    /// </summary>
    
    /// <param name="kernel">The kernel.</param>
    
private static void RegisterServices(IKernel kernel)
    {
      
  kernel.Bind<string>()
        .ToMethod(f =>
#pragma warning disable 0618 //disable obsolete warning as this is the ONLY place this method should be used in the application
          
  ProjectDb.Adapter.EfExtensions.CreateConnectionString(
#pragma warning restore 0618
          "data source=databaseSource;initial 
catalog=YourDbName;integrated 
security=True;multipleactiveresultsets=True;App=EntityFramework"))
      .Named("efString");

      
kernel.Bind(typeof(Project.Shared.Behaviors.IRepository<>))
  .To<ProjectDb.Adapter.DEVEntities>()
  .InThreadScope()
        
  .WithConstructorArgument("connectionString",kernel.Get<string>("efString"));


    }

Composition Root

I'm reading Dependency Injection in .Net by Mark Seemann

In response to http://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx

I'm only up to reading mid-way through your chapter on doing it right (and jumped to the asp.net webforms composition root after reading this blog post), but here is more of my reasoning.

The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. AnemicDomain Models - Martin Fowler

It becomes a 'real' domain model when it contains all (or most) of the behaviour that makes up the business domain (note I'm emphasising business logic, not UI or other orthogonal concerns). Anemic Domain Models - Stack overflow

I don't feel that this is headed into an Anemic domain model as the domain model assembly would contain all behaviors specific to the domain.

  Designs that share very little state or, even better, have no state at all tend to be less prone to hard to analyze bugs and easier to repurpose when requirements change. Blog article - makes sense but i could be missing multiple boats here.

The domain would have zero state, and would depend on interfaces not DTOs. This would make test-ability and analysis simple.

 Motivation for DTOs in the interfaces layer: presentation and persistence could all share the DTOs rather than having them duplicated in either place.
Barring that perceived gain, then the shared layer across all would just be interfaces.

 The UI could depend on interfaces only, but the same assembly would contain DTOs that the presentation layer and any persistence could share without having to be duplicated/rewritten. So the domain is completely persistence and presentation ignorant.

Experimental Technologies

Before I lose track of all the things I've been touching in the last 6 months, I wanted to say something on the matter of each and keep track of where I've been and where I might want to go.

Mef - twice (both plug-in UI projects)

Vs2010 Add-ins -

1.  checks all project reference to ensure none are absolute paths, one that d
2.  ExtensionsProject for my team
1. parses all project files 
2. locates .config files
3. checks for config values to be in compliance with team standards
4. checks your projects' FileCodeModel to confirm the code meets other team standards
5. will remove some project file customizations temporarily, confirm it builds in release mode, then brings up the svn commit dialog
6. allows you to store compliance information on your modules/projects on the team for easy access.
3. used a pluggable UI by importing an Action or using the default built-in messagebox if no extension is found.

FxCop/Code-check-in-policies

1. Team policy reminder/enforcers
1. warn on calls to forbidden methods
1.  GC.Collect
2. GC.AddMemoryPressure
3. Messagebox.Show
2. warn if inheriting directly from Windows.Forms or Windows.Control
3. warn if a control or form subclass constructor does not call InitializeComponent()
4. warn if a control property is not set per team standards
1. DialogBorderStyle must be fixed
5. error if you do not override certain virtual properties (legacy need from vs2005 designer bug)
6. error if you have code that raises a NotImplementedException
7. warn if you don't have hungarian notation to name controls
8. warn if fields are not private
2. Policy to ensure a project does not call a Config value or index that does not exist.

Wpf

• Mef extension  UI
• Web data scraper/exporter
• datagrid context menu

Mvc

• Mvc 2
• Lots of projects 2 at work, many more at home
• Mvc 3
• Got 2/3 through a project and had to go back to MVC2 due to changing requirements, transfer went very well.

Dependency Injection

• Unity - Nice DI framework from Microsoft.
• Ninject - Very nice lightweight DI framework
• Poor Man's - Did manual DI for the longest time, so happy to have finally switched to learning Ninject and Unity

MSBuild Custom tasks

• Wrote a task that walks all found project files under a path and determines safe build DirectedAcylicGraphs
• Detects Circular dependencies/references
• walks project files in parallel
• Wrote a task on the ordering task that will generate a properly parallelizing and multi-threading MsBuild project file.

Parallelization/threading/async

• Rx - wrote a producer consumer where a consumer can produce additional items to be consumed
• PLinq - used in Rx producer consumer to parallelize the Rx search
• Async CTP - have not used it quite yet, but did attend the 2010 PDC broadcast

ORMs -

• Linq-2-Sql - lots of personal projects
• EF4 - now that I've used it, I actually like it much better than linq to sql

Javascript cross site script without Preflight / Cross Origin Resource Sharing - also Http Access Control

• Wrote javascript that uses jQuery in a bookmarklet to allow users to save data from a page on one site cross-domain into a private secured store in a db, with group sharing options, aka Cross Origin Sharing requests

Unit Testing - 

• TypeMock - excellent for brownfield applications and no design for testability compromises

I'm sure I've forgotten some and did not get to looking at the future of where I want to go, but it's quite a nice start.

Application architecture

Based on the 1^st chapter of the book Dependency Injection in .Net it appears a more usable dependency hierarchy of an application is that the middle tier is the master with no dependencies on the User-Interface or Data layers. This is accomplished via interfaces(or abstract classes). So the user-interface should have no dependencies besides on the middle tier(business logic/Domain library). And the Data layer(s) should depend on the business logic tier.

The reason for this is that if the database itself changes form (we move from one sql server to another, or change the database design, or the data feed moves to ISeries instead of a mainframe, or to teradata instead of a mainframe) the only thing that needs to change is the data Layer. If we change the UI around (windows forms to web) the only thing that has to change should be the UI layer).  The middle tier(business logic/Domain library) should be the absolute heart of the application.

Another major reason for this is if the business logic needs to be changed the middle tier having no other dependencies should make it safer to make that change without worry for what the other moving parts are going to do.

The goal being to move this spaghetti type code:



To this clean structured layout where the UI or data access sections can be swapped out as needed:



The first chapter of the book is available online for free, and is where I read this information. The examples in it are fairly well written.