0
I have the following scenario,
1 System
Containing several functionalities, these functionalities, have some that are similar (Changes according to the User Profile).
Only I’m having a hard time organizing this in the project.
I am Creating a Base System, to call each different screen. Example:
System1=> Cadcli1
System2=>Cadcli2
What I wanted to do, eliminate these "Systems".
Doing it this way
System=> If profile 1 Chamatela Cadcli1 If not Profile2 Chamatela Cadcli2
Only how would you do it? if in the menu I already specify the form to Be Instantiated?
CadCli1 cadCli= New CadCli1()
CadCli1.Show();
I have several screens so I think it would not be feasible to stay doing if in the opening code of each screen.
I’m probably organizing the system structure in the wrong way.
[upd] I found a way to instantiate the form through Reflection.
Assembly assembly = Assembly.Load("clMod1");
Type t = assembly.GetType("clMod1.frmCadCli");
Form frmCadCli= (Form)Activator.CreateInstance(t);
frmCadCli.ShowDialog();
Dai would dynamically load the modules ("clMod1") through the Profile (configured in a table), Would that be the solution?
Create a screen for each registration, depending on the quantity (screens), layout difference, size of the project becomes unviable. Is the difference between one register and another really big? Have some sketch (canvas) to show?
– rubStackOverflow
Unfortunately I have enough screens with these variations, the layout difference in most cases is minimal, or I have too many fields, or some more action and made if it is of such profile. Another thing I need to do due to the requirements, is enable some screens and disable others according to the profile. It is very complicated the structure of the project.
– Andrew Alex
the way with Reflection would work yes, but I believe it is risky, since you already have the profile in the table, could make an enumerator of profiles, then a switch case with the profile that comes from the bank, and then instantiate and show the form as the profile.
– Thiago Friedman
@Thiagofalcão to thinking about that, what do you think would be risky? the Control of the table? the Maintenance of the Same?
– Andrew Alex
@Andrewalex believe that the way it will instantiate from the module is incorrect, I believe that the correct would be from the profile directly, in my understanding what will define the visualization of the module is the profile, so the switch case in the profile coming from the bank I think would be the most appropriate.
– Thiago Friedman
Using Reflection in large quantities can be really risky, it’s much more computationally costly to talk about than instantiating classes directly. Have you ever thought of inheritance?
– Thiago Silva