Some questions about Project Tracker

OregonCreative posted on Friday, October 13, 2006

PT is a great place to start for me because I have a similar project.  A couple of design questions.

Imagine if I wanted to have a collection of Projects that matched a specific set of criteria such as:

Projects that were started between 1/1/2006 and 3/31/2006 by resource ID X in the role of X.

I would like to work with these projects in the UI.  I would like to be able to report on this set of projects and also save the filter criteria for re-use later.

Basically, the "filter" I have used in the past is a SQL statement that is applied to a dataset object.  I usually provide a "wizard" type interface to let a user define a filter and a simple way to manage the filters.

What would be the best approach for this in CSLA?  I suppose I could modify the factory method of the Project List object and pass it a SQL query. Perhaps overload it and pass in a new type 'FilterObject' and then apply it.

Do either of these sound reasonable?  I would appreciate your thoughts.  Keep in mind that I am also interested in running reports based on the currently active filter.

Thanks Rocky! Great stuff in the latest book.

figuerres replied on Friday, October 13, 2006

I have been thinking of something along these lines ...

on one hand you could have "simple crtieria" like CSLA passes most of the time

x=1,y=2,z="foo" and in that case you could just save an xml snip with in the database and serialize / de-serialize that.

or you could get more involved and have a "complex criteria" class that might have something like:

Name - string
Operator - Enum list of common op's like ( =, >, < ,!, Like, IN)
Value - string

and then make the Criteria class be a List Of CriteriaExpressions

you could then store them in sql as xml also....

then you could get even more indepth with things like AND / OR and () nesting

but then you are really getting into a lot of work....

I think 90% would be coved with x>21 AND y in (21,34,56) AND Date < '1/2/3'

assume all expersions and "ANDED"  and you could pass a string to SQL to have a proc do a dynamic select

exec 'Select ......  WHERE ' + @params

just watch out for SQL injections!!!!

 

 

OregonCreative replied on Friday, October 13, 2006

Joins pose another interesting issue but could be handled by SPs as well.  That's probably the way to go.  thanks for your advice.

ajj3085 replied on Monday, October 16, 2006

Searching is a use case in and of it self.  Therefore, you should build business objects flexible enough to all the client program to specify the criteria you want.  Search this forum, this question has been asked many times before.

Build objects to represent your search, then have your data access code correctly interperate the values in these objects to build the sql string.

Do NOT under any circumstances having the UI pass Sql to the business layer.  Doing so violates the n-teir design in a big way.  Your UI should not need to change because the database changes.  That's the goal of the business layer, to hide such details.

Check out this thread to get you started thinking on some ideas.  But just remember, this is a use case, just like any other.  You'll have to build business objects to meet the requirements.

HTH
Andy