Source Code Refactoring: Difference between revisions
Wolfganguhr (talk | contribs) |
Wolfganguhr (talk | contribs) |
||
Line 38: | Line 38: | ||
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 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. | ||
[File:Reference-structure | [[File:Reference-structure-finance-common.JPG]] |
Revision as of 08:18, 19 Mayıs 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:
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.
Tools to investigate the dependencies
Actually I've used some additional tools
- the red gate reflector and
- a .NET Reflector Add-Ins named Graph
- this addin need the programm 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.
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:
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.
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.
So Move down all the code you want to use from an other module too.
Internal Code is deplaced
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.