I’m used to the layout that LLBLGen gives when it generates objects based on a database structure, which might generate the following class files for a given ‘User’ table in the database:
/EntityClasses/UserEntity.vb /CollectionClasses/UserCollection.vb This provides some base functionality for data access. However, when you want to implement business logic on top of that, how are you laying things out? For example, given a table structure that might look like this:
USER userId firstName lastName username password lockedOut What if you wanted to lock out a user? What code would you call from the presentation layer? Would you instantiate the UserEntity class, and do:
User = new UserEntity(userId) User.lockedOut = true User.Save() Or would you create a new class, such as UserHelper (/BusinessLogic/UserHelper.cs), which might have a LockOutUser function. That would change the code to be:
UH = new UserHelper() UH.LockOutUser(userId) Or would you extend the base UserEntity class, and create UserEntityExt that adds the new functionality? Therefore, the code from the presentation layer might look like:
User = new UserEntityExt(userId) User.LockOutUser() Or… would you do something else altogether?
And what would your directory/namespace structure and file/class naming conventions be?
I think what you are looking for is a service layer which would sit on top of the domain objects. You essentially have this with your second option although I might call it UserService or UserTasks. By encapsulating this LockUser process in a single place it will be easy to change later when there might be more steps or other domain objects involved. Also, this would be the place to implement transactions when dealing with multiple database calls.