Business Objects with relational data RRS feed

  • Question

  • Hi,

    I have a  class file with a number of properties a majority of these are foreign keys. This class is based on the table in the database.

    I then have a number of methods ie LoadById, LoadAll, Save etc. This works great for say admin areas etc

    The questions is if I bind LoadAll to a grid and say have a autogeneratecolumns it will show all the foreign keys. Do I create a view in the database and create a class from this? If I do this, these properties will be available in the Save, which of course won't save as they don't exist in that table which is ok, but not very clean to a new developer that may work on the project.

    I hope that made sense, if any one has any examples of how to work with relational data in a business objects that would be great.

    Many thanks

    Saturday, June 28, 2014 6:58 PM

All replies

  • Hi,

    (I think you should take a look at Entity Framework; its a framework designed to tackle exactly this problem of working with relational data and OO business objects).

    If you want to be able to use AutoGenerateColumns, then the solution would be to create classes that have exaclty the fields you want to display. Assuming that manual creation of the columns is not an option (you didnt exclude it, but I'm assuming you dont want to do it), then another option would be build you own customer column generation. You could use attributes on the properties to control this, for example.

    More generally, maybe you want to consider layering your code a bit more. I got the impression that you LoadAll methods are on the same class as the properties. I would not recommend to do this. Its cleaner to have a class that represents (an instance of) the business object, and another class that represents the set of persisted entities. This is where your LoadAll etc methods go. This is the essence of the Repository Pattern, and many people would call this their Repository class.

    But further layers can be useful too. Instead of binding the Grid to the collection of the business model classes, create another layer that just exposes the columns you want, from the collection. This is then taking you in the direction of having a ViewModel.

    Instead of try to get once class doing everything, refactor your code such that each class has a single, clear responsiblity. A new developer coming to the project would certainly thank you for finding code like this, becuase its much easier to understand and work with.


    Monday, June 30, 2014 9:10 AM
  • Hi Nick,

    Thanks for the reply, do you know of any good examples that show this in practice?

    I'm using Subsonic for the ORM at the moment, but would be keen to move to Entity Framework. Would be nice to see this functioning, I just seem come across snippets.

    Many thanks

    Monday, June 30, 2014 5:43 PM
  • Hi,

    Not so much a sample, but a great starting place for getting a solid foundation with all these patterns (and many more) is Martin Fowler's excellent book, Patterns of Enterprise Architecture.

    Don't discount code snippets, either. A lot of enterprise applications can seem dauntingly huge, but when done right the underlying architecture is simple. If you can build an EF model with 5 tables, then its not conceptually hard to build a model for 500 tables.


    Tuesday, July 1, 2014 7:20 AM