Reputation: 22619
I have a screen which does a basic search on a database employee table.
User will search by First Name, Last Name, Department, IsActive, etc.
As of now I have created a SearchParameter Class :
public class EmployeeSearchParameter
{
public EmployeeSearchParameterType SearchParameterType { get; set; }
public string EmployeeSearchParameterValue { get; set; }
}
public enum EmployeeSearchParameterType
{
FirstName = 1,
LastName = 2,
EmpId= 3,
IsActive = 4
}
Will this be flexible in case if I have more options that support Custom paging like start row number, end row number, sort by, etc?
Or I can create an abstract class Search and implement?
public abstract class Search
{
public virtual Int PageSize=10;
public virtual string SortBy="DESC"
//..etc
}
public class EmployeeSearchParameter:Search
{//stuffs
}
or ISearch interface
public class EmployeeSearchParameter:ISearch
{ }
Any input for better design/simplicity and not over-architecting the problem?
Upvotes: 0
Views: 1162
Reputation: 830
The downside of using the DAO pattern is similar to the downside of the repository pattern: You hide away the searching capabilities of the underlying technology in favour of writing a very limited set of possible queries.
If your DAO / repo begins to expose ever more and ever more flexible search capabilities, it's very likely that the implementation will approach a similar layout to how your DAL works anyways; it is likely that you will start to develop a Query type to express more complex relations. And this already exists in various DB access technologies. (And is, i believe, a more c# idiomatic way to phrase search queries, compared to the DAO.)
There are examples on SO and elsewhere for how query types might look; if you can expose your data through IEnumerable
(or probably better IQueryable
), accessing it through LINQ would be very flexible and powerful.
Upvotes: 0
Reputation: 14309
Your *Search*
class is actually what the DAO Pattern should be used for. If you call it differently your project will not be easily understood by other developers. In concrete, you will define an interface IEmployeeDao
and corresponding implementation EmployeeDao
. The public interface will include CRUD and finder methods e.g. create
, update
, delete
, findByName
, etc. For sample code in C# You should Google for DAO and Value List handler implementations for C#. I am only aware of sample code for the Java platform.
The second use-case you mention of navigating the results produced by the DAO implementation is another separate pattern, the Value List Handler pattern that builds on top of your DAO implementation and provides functionality for navigating the results in different ways.
Upvotes: 2