I’m unsure how to deal with the UserDetail class.
Program; A virtual account hierarchy, with UserAccounts which can only have transactions towards a MainAccount. But the UserAccounts can place some type of bets, which will be a profit/loss towards the account balance.
It feels logical to have MainAccount as the database aggregate root, as the accounts form the most important data. As it looks now, it may seem ok to have the UserDetail as part of the account aggregate, but I it could be useful to create a user even before an account has been created. And perhaps a user also may be allowed to have two accounts. Then what?
I guess the UserDetail could be simply a stand-alone aggregate. But in such case, how would I load the respective UserDetail when loading the account aggregate?
Please, if you have some thoughts around this, would be much appreciated.
Btw, I’m using FluentNHibernate.
Domain:
public class MainCashAccount
{
public int Id { get; set; }
public IList<UserCashAccount> UserCashAccounts { get; set; }
public IList<Transaction> UserAccountTransactions { get; set; }
}
public class UserCashAccount
{
public int Id { get; set; }
public UserDetail User { get; set; }
public IList<Bet> Bets { get; set; }
public UserConnection Connection { get; set; } // Not persisted/mapped
}
public class UserDetail
{
public int Id { get; set; }
public string Name { get; set; }
public string LoginName { get; set; }
public string Password { get; set; }
}
Other:
public class UserConnection
{
public TcpClient TcpClient { get; set; }
EDIT:
Possible solutions: (??)
One-Directional
Class UserCashAccountMap
...
HasOne(x => x.User).Cascade.None()
Bi-Directional
Class UserDetail
...(as above)
public UserCashAccount Account {get; set;}
Class UserCashAccountMap
...
HasOne(x => x.User).Cascade.None()
Class UserDetail
HasOne(x => x.Account).Cascade.None().Inverse()
..Or Reference instead of HasOne, for allowing multiple accounts per user.
By having the primary key of the MainAccount object be a foreign key on the UserDetail object.
The question you specifically revolves around to have self referencing entities or not, from your statements I quoted you could define your model in a bunch of ways. You could do
or any combination of these 2. You can also choose to not reference 1 side of this relationship at all and not have a bi-directional relationship.
Edit: Responding to your comment. You do not want to use
HasOne(), HasOne is an extremely rare type of association that is truly 1-to-1, almost no databases ever have relationships coded as a 1-to-1 they are almost always many-to-1. This is aReferences()relationship.In the situation of a HasOne both objects share the same primary key. This design is almost never used in database systems.
One note I did originally have an error in my design, to have a bi-directional association the UserDetails would actually be a collection on the UserAccount object to avoid requiring a true HasOne association.