i have a question regarding class design using csla. here is my scenario
say i have a user table, and a userpermissions table (1 to many)
scenario 1. i need a list of user names and the pemission names they're assigned
scenario 2. i need a list of user id, usernames
scenario 3. i need just a list user names and the last time that user logged in
in the above 3 scenarios, by using a table based design, i only need 2 classes. tblUsers and tblPermissions, list<permissions> would be a member of the user class, and i can have 3 non-shared functions that return me back a User or List<User> object. the disadvantage of this approach is the User class is convoluted, as it has multi purposes so you can't really pinpoint what the User class actually does.. its simply just a collection of a bunch of functions that return different things based on what you need
by using CSLA and a generator (of your choice), then if its to be completely business object based, then technically its going to create several classes, (at least one class per scenario) because i don't need a loggedin date property for scenario 2, but in the table based approach, i'd have that property available anyways. This problem i see with this approach is that the many classes you will have to cover each scenario, i foresee a lot of duplication of code.
is there a middle ground anywhere? the point i'm getting at is that while basing your objects around business rules, you'll get exactly the data you need with only the properties and methods that you need , but you'll be repeating a lot of code, and while one can argue that "that's what code generators are for", i'm more concerned about bulky DLL's.
Your problem (bloated code and bulky dll) is because you are using a code generator, not because you are using Csla.
If you are just starting with Csla, which it looks like from your post (if not, then I apologize for the assumtion), then you may be starting at the wrong end using a code generator. If I were you I would take the particular example you have given and hand code it from one end to the other while going through the Csla book. You don't want to miss out on the elegance of this framework while churning out code with a generator.
As a general rule, you will create your Csla classes based on your use case scenario, not necessarily based on your database structure. Looking at your scenarios, you can create one ReadOnlyList containg UserId, UserName and LastTimeLoggedIn which will take care or Scenario #2 and #3. As for scenario #1, to begin with you will need a third table because it will require a many to many relation. (One user can have many permisions, and a permission may be given to many users).
Jav
Copyright (c) Marimer LLC