Moving code from a Window/UserControl to outside in order to make it reusable!
-
Hi, I have a usercontrol in my WPF application, and there is a code behind file suppose EmployeeEditor.xaml.cs which has some code to modify. For e.g; I have a Employee as defined below Class Employee { public string Name {get; set;} public uint Id {get; set;} } I have a UserControl to edit the Employee information which has EmployeeEditor.xaml and EmployeeEditor.xaml.cs There are methods in EmployeeEditor class to modify the list of employee - AddEmployee() - RemoveEmployee() - RenameEmployee() These methods has business logic to update the information in the data object/database. The life of EmployeeEditor class is till the user control is displayed and it dies on closing it. I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods. One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter. Other solution can be to create a separate class to which will perform all the operations and keep the dependencies. Please let me know if this problem fits into any design pattern and what could be the better solution? Thanks in advance!
-
Hi, I have a usercontrol in my WPF application, and there is a code behind file suppose EmployeeEditor.xaml.cs which has some code to modify. For e.g; I have a Employee as defined below Class Employee { public string Name {get; set;} public uint Id {get; set;} } I have a UserControl to edit the Employee information which has EmployeeEditor.xaml and EmployeeEditor.xaml.cs There are methods in EmployeeEditor class to modify the list of employee - AddEmployee() - RemoveEmployee() - RenameEmployee() These methods has business logic to update the information in the data object/database. The life of EmployeeEditor class is till the user control is displayed and it dies on closing it. I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods. One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter. Other solution can be to create a separate class to which will perform all the operations and keep the dependencies. Please let me know if this problem fits into any design pattern and what could be the better solution? Thanks in advance!
Rags1512 wrote:
I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods.
There's usually no undo/redo on the database-level. Check out the Memento-pattern, you'll see that it'd be a bit work to implement correctly.
Rags1512 wrote:
One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter.
Other solution can be to create a separate class to which will perform all the operations and keep the dependencies.What dependencies? FWIW, I'd put it in a separate class, which would be embedded in the UserControl. Similar to;
class MyControl: UserControl
{
class MyControlHelper: object
{
}
}Referring from the UC to the helper-class, is like creating a mini-DAL for your control; all IO is situated in that class. The biggest advantage is that you could write another MyControlHelper-implementation (for say, supporting another database like Oracle or Sqlite) and hook it in there. Which parameters would you be passing? The way I see it, you'd minimal pass an
Employeeobject. Perhaps a ConnectionString, but that'd be it. If you want to prevent writing a long signature (lot's o' params), then wrap them in their own object (like MyControlHelperAddEmployeeArgs). Hope this gets you a bit in the right direction :)Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
Rags1512 wrote:
I wanted to move above methods outside this class, so that they can be used elsewhere in a functionality such as Undo/Redo which will create/delete an employee using AddEmployee/RemoveEmployee methods.
There's usually no undo/redo on the database-level. Check out the Memento-pattern, you'll see that it'd be a bit work to implement correctly.
Rags1512 wrote:
One solution is to move those methods to a helper which i don't feel to be appropiate as I need to pass all the dependencies of AddEmployee() method as a parameter.
Other solution can be to create a separate class to which will perform all the operations and keep the dependencies.What dependencies? FWIW, I'd put it in a separate class, which would be embedded in the UserControl. Similar to;
class MyControl: UserControl
{
class MyControlHelper: object
{
}
}Referring from the UC to the helper-class, is like creating a mini-DAL for your control; all IO is situated in that class. The biggest advantage is that you could write another MyControlHelper-implementation (for say, supporting another database like Oracle or Sqlite) and hook it in there. Which parameters would you be passing? The way I see it, you'd minimal pass an
Employeeobject. Perhaps a ConnectionString, but that'd be it. If you want to prevent writing a long signature (lot's o' params), then wrap them in their own object (like MyControlHelperAddEmployeeArgs). Hope this gets you a bit in the right direction :)Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Thanks!