Design Help

tna55 posted on Sunday, November 11, 2007

I have a database table, Project, with tons of fields. However, some of these properties are used in Use Case 1 and some in Use Case 2.

As I understand from responsibility driven design, I should create two class here, Project1 dealing with Use Case 1 and Project2 dealing with Use Case 2. Use Case 1 is 'Adding a Project' however adding a project does not mean filling all the fields in database. Project1 deals with Use Case 1 so I am thinking that the validations of only those properties that Project1 (Use Case1) use, should go in Project1 and validations of properties that Project2 (Use Case2) use, should go in Project2.

Is that the correct way?

Tahir

stefan replied on Monday, November 12, 2007

You can stick with just one object here, if you are willing to write some more lines of code:

All the validationrules that are only necessary for an existing object (here: UseCase 2) must check for
IsNew == false. This means that you cannot use the rules that come with CSLA and have to write your
own set, even for the simple ones like 'StringRequired' ...depends on how many that will be in your case.

Another hint:

If you follow the 'separate objects for separate use cases' route and you need a concurrency mechanism
for each use case ('Adding a Project' does not!), then the solution with one timestamp column will not
work any more. Maybe inserting a new timestamp column for each use case can be a solution.
Again, it depends on how many there will be.

Stefan