Source Code Refactoring: Difference between revisions

From OpenPetra Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 5: Line 5:
[[File:Reference-structure.JPG]]
[[File:Reference-structure.JPG]]


Here the assembly dependencies are shown i.e. which assemblie use which other assembly. The details of this diagram are not so important at this point. Actually it is more important to understand that there exists a dependecy structure and how to handle it.  
Here the assembly dependencies are shown i.e. which assembly use which other assembly. The details of this diagram are not so important at this point. Actually it is more important to understand that there exists a dependency structure and how to handle it.


== Tools to investigate the dependencies ==
== Tools to investigate the dependencies ==
Line 13: Line 13:
# the [http://reflector.red-gate.com/download.aspx?TreatAsUpdate=1 red gate reflector] and
# the [http://reflector.red-gate.com/download.aspx?TreatAsUpdate=1 red gate reflector] and
# a [http://reflectoraddins.codeplex.com/wikipage?title=Graph&referringTitle=Home .NET Reflector Add-Ins named Graph]
# a [http://reflectoraddins.codeplex.com/wikipage?title=Graph&referringTitle=Home .NET Reflector Add-Ins named Graph]
# this addin need the programm [http://research.microsoft.com/en-us/downloads/f1303e46-965f-401a-87c3-34e1331d32c5/default.aspx Microsoft Glee] which now has become a commercial tool named "Microsoft Automatic Graph Layout (MSAGL)". The cost free version is availiable by refering the link and will work well.
# 3. this add in needs the program [http://research.microsoft.com/en-us/downloads/f1303e46-965f-401a-87c3-34e1331d32c5/default.aspx Microsoft Glee] which now has become a commercial tool named "Microsoft Automatic Graph Layout (MSAGL)". The cost free version is available by referring the link and will work well.


Install this tools check out the sources, run "nant generateSolution" and you can load the dlls to investigate the reference structure. On the other side I have the [http://www.sparxsystems.com.au/ Enterprise Architect] and for this program exists an plug in too [http://blog.lieberlieber.com/2009/09/24/rizosuite/ RizoSuite]. But it seems that it needs a higher level of EA.
Install this tools check out the sources, run "nant generateSolution" and you can load the dlls to investigate the reference structure. On the other side I have the [http://www.sparxsystems.com.au/ Enterprise Architect] and for this program exists an plug in too [http://blog.lieberlieber.com/2009/09/24/rizosuite/ RizoSuite]. But it seems that it needs a higher level of EA.


== Detailed Problems ==
== Detailed Problems ==
Line 30: Line 29:
[[File:Reference-structure-partner-ui-top.JPG]]
[[File:Reference-structure-partner-ui-top.JPG]]


This is not only a cosmetical problem. Die Graph-Tool automatically puts the dependent assemblies below thoose one who calls the routines. If Ict.Petra.lib.MPartner call a routine in Ict.Petra.lib.MPartner, this assemby itself and all otheres above it cannot support the connector modul Ict.Petra.lib.MPartner.ui again. Of course it can support an other connector, but this is't a good idea too.
This is not only a cosmetically problem. Die Graph-Tool automatically puts the dependent assemblies below those one who calls the routines. If Ict.Petra.lib.MPartner call a routine in Ict.Petra.lib.MPartner, this assembly itself and all others above it cannot support the connector module Ict.Petra.lib.MPartner.ui again. Of course it can support an other connector, but this isn’t a good idea too.  


So Move down all the code you want to use from an other module too.
So Move down all the code you want to use from an other module too.


=== Internal Code is deplaced ===
=== Internal Code is displaced ===


Let us have a look to the position of Ict.Petra.Server.lib.MFinance.Common. The position was "too high" in the hierarchy and in the first picture of the report you can see the correct postion. Not common calls gift and gl, it is vice versa. The rule is the same as above. Disconnect the forbidden reference manually and move the classes until it works again.
Let us have a look to the position of Ict.Petra.Server.lib.MFinance.Common. The position was "too high" in the hierarchy and in the first picture of the report you can see the correct position. Not common calls gift and gl, it is vice versa. The rule is the same as above. Disconnect the forbidden reference manually and move the classes until it works again.  


[File:Reference-structure-partner-finance-common.JPG]
[[File:Reference-structure-finance-common.JPG]]

Latest revision as of 08:25, 19 May 2011

Motivation

A set of cyclic reference errors enforced to run a specific type of source code refactoring. In order to understand this we have a small diagram like this:

Reference-structure.JPG

Here the assembly dependencies are shown i.e. which assembly use which other assembly. The details of this diagram are not so important at this point. Actually it is more important to understand that there exists a dependency structure and how to handle it.

Tools to investigate the dependencies

Actually I've used some additional tools

  1. the red gate reflector and
  2. a .NET Reflector Add-Ins named Graph
  3. 3. this add in needs the program Microsoft Glee which now has become a commercial tool named "Microsoft Automatic Graph Layout (MSAGL)". The cost free version is available by referring the link and will work well.

Install this tools check out the sources, run "nant generateSolution" and you can load the dlls to investigate the reference structure. On the other side I have the Enterprise Architect and for this program exists an plug in too RizoSuite. But it seems that it needs a higher level of EA.

Detailed Problems

A connector is referenced

Le us have a look onto the special dependency:

Reference-structure-partner-ui.JPG

Here the Assembly Ict.Petra.Server.lib.MPartner uses the assmbly Ict.Petra.Server.lib.MPartner.ui. You can easily find the reason for this, if you delete the ui-reference in Ict.Petra.Server.lib.MPartner and recompile. Then you are asked to remove a set of "using Ict.Petra.Server.MPartner.Extracts.UIConnectors;" lines and you can recompile again. Then you get a list of errors like "Missing TPartnerEditUIConnector" and then you have to realize that you have to move the code from Ict.Petra.Server.lib.MPartner to Ict.Petra.Server.lib.MPartner.ui. The final goal is to move the connector to the top.

Reference-structure-partner-ui-top.JPG

This is not only a cosmetically problem. Die Graph-Tool automatically puts the dependent assemblies below those one who calls the routines. If Ict.Petra.lib.MPartner call a routine in Ict.Petra.lib.MPartner, this assembly itself and all others above it cannot support the connector module Ict.Petra.lib.MPartner.ui again. Of course it can support an other connector, but this isn’t a good idea too.

So Move down all the code you want to use from an other module too.

Internal Code is displaced

Let us have a look to the position of Ict.Petra.Server.lib.MFinance.Common. The position was "too high" in the hierarchy and in the first picture of the report you can see the correct position. Not common calls gift and gl, it is vice versa. The rule is the same as above. Disconnect the forbidden reference manually and move the classes until it works again.

Reference-structure-finance-common.JPG