Source Code Refactoring: Difference between revisions
Wolfganguhr (talk | contribs) |
Wolfganguhr (talk | contribs) |
||
| Line 33: | Line 33: | ||
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 | === 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 | 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-finance-common.JPG]] | [[File:Reference-structure-finance-common.JPG]] | ||
Latest revision as of 08:25, 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 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
- the red gate reflector and
- a .NET Reflector Add-Ins named Graph
- 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:
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 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.
