Hi Owen,

There are at least 3 things you could do:

1) Extract business objects (or data objects) such as User into a third assembly
which you then reference from both > Business.dll and DataAccess.dll. In
this scenario they will share the common type. If you want to have "active"
objects

eg.:

User user = new User("username", email@something.com");
user.Save();

then it's probably a bad solution but if the classes are only for carrying
data then that may be the way to go.

2) Make UserCRUD Get methods return IDataReader and construct the object
in the Business.dll (you can have the object construction logic in another
assembly). Insert methods would then have to take multiple parameters (each
property of your User object eg.: UserCRUD.Insert(string userName, string
email) instead of accepting the actual instance of the User class).

3) Make the User class (Business.dll) inherit from UserData class (DataAccess.dll
or better yet a separate assembly). Data access layer would then return an
instance of UserData (only a data carrying object) class which could be transformed
into a business object (User class). This would allow the business objects
to call the data access layer and provide the above mentioned user.Save()
functionality.

You can also look around for ORM tools, see what kind of code those give
you and use those ideas.

Does that help?

Best regards,
Robert Wilczynski.