|
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 Employee object. 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 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
