I am in the middle of a big dilemma.
In my app, we have tons of methods for selecting information based on different filters, an in many cases bringing different fields/attributes as well.
I thought of naming the methods based on the filter names (e.g. SelectEmployeeOnName (name) would bring all employees that have that name), other option would be to overload a lot of methods, but then this might not work in the cases where I had n methods with the same filter structure, differing only in the returned structure (the object).
Any idea on this

Approach for creating class method
worldhello
enum Filters
{
FirstName,
LastName,
//etc
}
public string SelectEmployeeByFilter(params Filters[] list)
{
//code
}
PS I hope there isn't a double-post, I was unable to edit my previous post so I tried to delete it, so yeah.
treckamerica
cashrolls2
To minimize the method count you should drop the Employee, why creatin one big class that contains of the find methods for all objects You should seperate this in diffent classes, for example:
Customer customer = CustomerRepository.FindByName( "sande" );
Order order = OrderRepository.FindById( 5122 );
This way the object name OrderRepository gives the indication that it is about Orders.
And don't use Get as prefix for the methods, following the Microsoft rules and FxCop you should not start with Get because, Get is for properties.
Can't agree more!
Anaray
This is a shot in the dark but use an indexer which could take an enum value of the operation to execute. Code could look like this:
enum Operations
{
Name,
Weight,
Status,
// ...
}
public string this[Operation op]
{
get
{
switch (op) ...
}
}
Allen_Iowa
Pete Orologas
You should never put Data Access Code in your Domain Objects! Because then there is no visable line and you can't reuse the classes elsewhere. And there is no need to, you want all the Orders of a Customer
Order[] orders = OrderRepository.FindAllByCustomer( selectedCustomer );
What if the requirements changes and you have to make the Collection classes accessable trought Remoting, then you only have to change the proxies in you Collection classes and in the UI Layer, there shouldn't be any Data Access. But there are Domain Objects in your UI Layer but you want to hide the Data Access so the programmers of the UI Layer can only use the UseCase/MVC classes.
There is no golden rule and this is overkill in small applications that aren't N-tier, but it is my my humble opinion.
LynnOoi