Firstly, This might seem like a long question. I don’t think it is… The code is just an overview of what I’m currently doing. It doesn’t feel right, so I am looking for constructive criticism and warnings for pitfalls and suggestions of what I can do.
I have a database with business objects.
I need to access properties of parent objects.
I need to maintain some sort of state through business objects.
If you look at the classes, I don’t think that the access modifiers are right. I don’t think its structured very well. Most of the relationships are modelled with public properties. SubAccount.Account.User.ID <– all of those are public..
Is there a better way to model a relationship between classes than this so it’s not so “public”?
The other part of this question is about resources:
If I was to make a User.GetUserList() function that returns a List, and I had 9000 users, when I call the GetUsers method, it will make 9000 User objects and inside that it will make 9000 new AccountCollection objects. What can I do to make this project not so resource hungry?
Please find the code below and rip it to shreds.
public class User {
public string ID {get;set;}
public string FirstName {get; set;}
public string LastName {get; set;}
public string PhoneNo {get; set;}
public AccountCollection accounts {get; set;}
public User {
accounts = new AccountCollection(this);
}
public static List<Users> GetUsers() {
return Data.GetUsers();
}
}
public AccountCollection : IEnumerable<Account> {
private User user;
public AccountCollection(User user) {
this.user = user;
}
public IEnumerable<Account> GetEnumerator() {
return Data.GetAccounts(user);
}
}
public class Account {
public User User {get; set;} //This is public so that the subaccount can access its Account's User's ID
public int ID;
public string Name;
public Account(User user) {
this.user = user;
}
}
public SubAccountCollection : IEnumerable<SubAccount> {
public Account account {get; set;}
public SubAccountCollection(Account account) {
this.account = account;
}
public IEnumerable<SubAccount> GetEnumerator() {
return Data.GetSubAccounts(account);
}
}
public class SubAccount {
public Account account {get; set;} //this is public so that my Data class can access the account, to get the account's user's ID.
public SubAccount(Account account) {
this.account = account;
}
public Report GenerateReport() {
Data.GetReport(this);
}
}
public static class Data {
public static List<Account> GetSubAccounts(Account account) {
using (var dc = new databaseDataContext()) {
List<SubAccount> query = (from a in dc.Accounts
where a.UserID == account.User.ID //this is getting the account's user's ID
select new SubAccount(account) {
ID = a.ID,
Name = a.Name,
}).ToList();
}
}
public static List<Account> GetAccounts(User user) {
using (var dc = new databaseDataContext()) {
List<Account> query = (from a in dc.Accounts
where a.UserID == User.ID //this is getting the user's ID
select new Account(user) {
ID = a.ID,
Name = a.Name,
}).ToList();
}
}
public static Report GetReport(SubAccount subAccount) {
Report report = new Report();
//database access code here
//need to get the user id of the subaccount's account for data querying.
//i've got the subaccount, but how should i get the user id.
//i would imagine something like this:
int accountID = subAccount.Account.User.ID;
//but this would require the subaccount's Account property to be public.
//i do not want this to be accessible from my other project (UI).
//reading up on internal seems to do the trick, but within my code it still feels
//public. I could restrict the property to read, and only private set.
return report;
}
public static List<User> GetUsers() {
using (var dc = new databaseDataContext()) {
var query = (from u in dc.Users
select new User {
ID = u.ID,
FirstName = u.FirstName,
LastName = u.LastName,
PhoneNo = u.PhoneNo
}).ToList();
return query;
}
}
}
This answer has ended up containing a lot of buzz word headings. Hopefully I explain each one and why it applies here. I think each concept I introduce below is worth considering – they aren’t always applicable but I find they are all things I personally find valuable when I think about the structure of a system.
Single Responsibility
Start by thinking about the responsibility of each object – what is its job? Generally you’ll find a better design once you decide on a single job for each class. Currently a lot of your classes are doing too much, holding logic that should really exist as services.
The first example of the above is your User class:
Why does this provide a method that retrieves users from the data source? That functionality should be moved out into a users service.
Another key example of this is the GenerateReport method on the SubAccount – don’t have your report generation logic so tightly tied to the SubAccount object. Splitting this out will give you more flexibility and reduce the change of changes to your SubAccount breaking the report logic.
Lazy Loading
Again looking at your User class – why does it load all the users accounts on instantiation? Are these objects always going to be used every time you work with a User?
It would generally be better to introduce lazy loading – only retrieve an account when you need it. Of course there are times when you want eager loading (if you know you will want the object soon so want ot reduce database access) but you should be able to design for these exceptions.
Dependency Injection
This sort of follows on from both the lazy loading point and the single responsibility point. You have a lot of hard coded references to things like your Data class. This is making your design more rigid – refactoring your data access to introduce lazy loading, or changing the way that user records is retrieve is much harder now that many classes are all directly accessing the data access logic.
Digest objects
Hat tip to Cade Roux – I’d never heard the term Digest objects, usually called them light weight DTOs.
As Cade says, there is no reason to retrieve a rich list containing fully functioning user objects if all you are doing is displaying a combo box of user names that is bound to the unique ids.
Introduce a light weight user object that only stores the very basic user information.
This is again another reason to introduce a services/repository abstraction, and some sort of dependency injection. Changing the types of objects retreived from the data store becomes much easier when you have encapsulated your data retrieval away from your actual objects, and when you are not tightly bound to your data access implementation.
Law of Demeter
Your objects know too much about the internal structure of each other. Allowing drill down through a User to the Accounts and then to the SubAccount is muddling the responsibility of each object. You are able to set sub account information from the user object when arguably you shouldn’t be.
I always struggle with this principle, since drilling through the heirarchy seems very convenient. The problem is that it will stop you thinking proberly about the encapsulation and role of each object.
Perhaps don’t expose your Account object from user – instead try introducing properties and methods that expose the relevant members of the Account object. Look at a GetAccount method instead of a Account property, so that you force yourself to work with an account object rather than treat it as a property of the User.