Our db is optimized for minimum join count (partially denormalized). E.g. our
User entity contains account data (nickname, facebook id, etc), user numerical statistics (total games played, total wins, etc), guild related user information (guild id, membership type, etc) and so on - everything in the same table.
We use ORM - NHibernate. The
user table is mapped (with all the fields) to
Now I'm refactoring a model class
AccountManagementService that provides a possibility to do some actions on an enclosed
User. The model has the two dependencies: NHibernate and the
User entity. The model logic is strictly tied to ORM methods (performs selects, does updates).
I think it's bad that the model knows about so many fields which it's not going to use. It doesn't need
User.GuildId, statistics, etc. But since the model already should use ORM it's logical that it should know about entity classes.
I'm also worried that some operations with
User should be done only through special services but other services theoretically can access and change any of the
User's fields. E.g.
AccountManagementService should not change
User.Money directly but use
UserMoneyService instead. But from a compiler viewpoint such change is perfectly valid.
Should I introduce other abstraction layers between services and entities to control an access and how can I do it? Can you see any other possibilities to improve the situation?