Currently I'm working on a enterprise app and I've some questions regarding the design of the Business Entity Layer and the underlying database.
I'm modeling a domain model in a Business Entity Layer. In my domain model I've users. Each user is contained in one or more user groups. For now, there are just two user groups: junior and senior users. A straight forward approach would be implementing a User class and a UserGroup enumeration. Actually, a user can be contained in both user groups, so this enumeration would be decorated with the Flags attribute. In the database I then would have a User table and a UserGroupContainment table that has two columns: UserId and UserGroup. But I know, somewhere in the future, my app will have to cope with user-group management, i.e. administrators can add and remove custom user groups. So I'll probably will have to introduce a UserGroup class in my Entity Layer and a UserGroup table in my database. The UserGroup enumeration will be removed than and a User object will get associated with one or more UserGroup objects. The UserGroup column in the UserGroupContainment table will become a foreign key to the UserGroup table. But --- and this what I'm struggling with --- the junior-users and senior-users group will need a special treatment: they're system group and the app should not allow them to be removed. How will I implement that? Should I hardcode these restrictions in the Entity Layer. Should there be an extra column in the UserGroup table that indicates whether a group is a system group? I guess this is an issue that arises quite often, so I'm very interested in hearing how others solve this problem. I really haven't decided which way to go with the implementation of my app, so I'm open to any suggestion... -- Stefan You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
