locked
guidelines for loose coupling? RRS feed

  • Question

  •  

    Are there any well defined guidelines (Microsoft or otherwise) for when / how to implement loose coupling between .NET assemblies?   When is a coupling too strong?    When is coupling too loose?

     

    Code Snippet

    For example:

     

    AssemblyA

    SqlConnection conn = new SqlConnection(m_auditConnect);

    conn.Open();

     

     

     

     

    Some would argue that AssemblyA is now tightly coupled to the System.Data assembly.  I could replace this type of object construction with more dynamic code.   I could bake my own dynamic code that uses reflection to load some config file specified assembly and construct/bind a new instance to some interface (IDbConnection).  I could write some code to use a DI container to abstract the construction out.  However,  these dynamic construction options seem a bit extreme (and probably slow to boot).

     

    I understand that loose coupling is needed to facilitate unit testing.   However, loose coupling strikes me as similar to database normalization.   I can normalize my database to the Nth degree but doing so makes the db harder to  use.  Similarly, de-coupling code  to the Nth degree certainly can make coding / deployment much more difficult.   

     

    Are their any good guidelines for when to de-couple and when not to de-couple?

     

     

    thanks!

     

     

     

     

    Wednesday, November 12, 2008 2:48 AM

Answers

  • What you decouple depends on your requirements and what you think will change in the future. 

     

    For instance, in the projects I am involved in it would be a requirement to have the flxibility to change databases rather than use something other than the system.data assembly.

     

    If you want to support multiple databases it would be a concern that you are tightly coupled to a specific class within the system.data assembly.

     

    If you don't feel the need for dependancy injection, your code can be less tightly coupled through the use of interfaces and factories;

     

    AssemblyA

    IDBConnection conn= new SqlConnection(m_auditConnect)

    conn.open

     

    We have removed the reference to SqlConnection from the left hand side of the statement.

     

    We can further decouple by using the factory pattern;

     

    AssemblyA

    IDBConnection conn= DataFactory.CreateConnection(m_auditConect)

     

    Now we have removed the right hand side reference.

     

    Although AssemblyA is still tightly coupled to the system.data assembly it is no longer coupled to a specific class within that assembly. 

     

    Therefore, you will have less code to change should the database you use change in the future.

     

    In summary, de-coupling is about mitigating risk and the impact of change.

     

    How much effort and what you decouple depend largely on your requirements, your environment and what you think will change in the future.

     

    Hope this helps.

    Tuesday, November 18, 2008 2:12 PM

All replies

  • There is no strick guideline on how much you could course grain and fine grain your loose coupling Vs creating cohesion in your application.  I usually break things apart as simple logical unit that can be maintained easily that driven by the business functionality, expected changes in near term and long term, supportability, etc.,

     

    { Gaja; }

    Wednesday, November 12, 2008 4:54 AM
  • Agree with Gaja.

     

    Change is inevitable to a system. If you can seggregate your system into smaller units and follow the contract-based design & development, the ability fo the system to adapt to changes improves drastically.

     

     

    Wednesday, November 12, 2008 4:16 PM
  • What you decouple depends on your requirements and what you think will change in the future. 

     

    For instance, in the projects I am involved in it would be a requirement to have the flxibility to change databases rather than use something other than the system.data assembly.

     

    If you want to support multiple databases it would be a concern that you are tightly coupled to a specific class within the system.data assembly.

     

    If you don't feel the need for dependancy injection, your code can be less tightly coupled through the use of interfaces and factories;

     

    AssemblyA

    IDBConnection conn= new SqlConnection(m_auditConnect)

    conn.open

     

    We have removed the reference to SqlConnection from the left hand side of the statement.

     

    We can further decouple by using the factory pattern;

     

    AssemblyA

    IDBConnection conn= DataFactory.CreateConnection(m_auditConect)

     

    Now we have removed the right hand side reference.

     

    Although AssemblyA is still tightly coupled to the system.data assembly it is no longer coupled to a specific class within that assembly. 

     

    Therefore, you will have less code to change should the database you use change in the future.

     

    In summary, de-coupling is about mitigating risk and the impact of change.

     

    How much effort and what you decouple depend largely on your requirements, your environment and what you think will change in the future.

     

    Hope this helps.

    Tuesday, November 18, 2008 2:12 PM