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 User class.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?
Abstracton layer to control services access to denormalized db entity
c#;architecture;database;layers;nhibernate