Login | Register | Contact Us | Faq
	Home Forums Meetings & Events About Us	Search

Search

08-19-2005, 8:59 AM tbarcz Joined on 06-22-2005 Posts 44 C# building classes/object Ok, so this has come up for debate and I wanted to see what you guys thought. I have 3 logical objects; Players, Events, PlayerEvents (PlayerEvents is a table that contains PlayerEventID (PK), PlayerID (FK), EventID (FK), ....) I think that by the naming it should be clear the mappings....but if it isn't just let me know. Ok so here's the question.  Say you want to know all the events the player has been to.  Quite simple: SELECT * FROM PlayerEvents WHERE PlayerID = @PlayerID The problem is that when I run the query above and want to display the results, you really don't have all the information that would be useful.  The above query will tell you that at Event with the EventID 112, the player with PlayerID = 12, had a score of 10 PlayerEventID      PlayerID      EventID      Score         20                    12              112            10   In reality when you display this EventID 112 means nothing.  REally you want to display the Events name, which requires you to go the the events table.   So finally after all of that here is the question...which of the following is the best way to accomplish that (best = speedy, easy to maintain, someone standard in the industry)   1)  My business, PlayerEvent could simply have a member of type Event.  Such that each PlayerEvent would load the individual event.  I would access this in code by Player.Event.EventName. The downfall to this I see is that for every PlayerEvent I load, I'm now loading an Event, which requires another call to the database.  To help this I can offload the loading of the Event only when it's needed.   2) Have by business PlayerEvent have more members, including EventName, which would be readonly (via a property with only GET defined).  I would avoid the pitfalls of #1 (above) by querying the database for the join (SELECT * FROM PlayerEvent INNER JOIN Event ON PlayerEvent.EventID = Event.EventID). The downfall to this I see is that now my PlayerEvent object contains items that are not really related at all the the PlayerEvent object at all.  Maybe I'm being overly anal by coding my business objects to look very similar to my database structure, if so please advise.   3) Something else I haven't thought of.    Report

08-19-2005, 10:09 AM jbrunken Joined on 04-05-2005 Cedar Rapids Posts 66 Re: C# building classes/object This is a scenario that has come up a lot for me, and honestly if there is an "Induststry Standard" solution/answer to this, I don't know it... I guess I would answer the question by analyzing how and when the data/objects are likely to be access and used. If the event information is almost always going to be used, I would probably construcat all of the objects from the results of a single query. On the other hand, if the event information is seldom accessed, I would probably load it seperately when needed. However...  In reality, I would probably go with a hybrid solution where the event object (and it's basic information) is loaded with the player info, but when less used information is needed, the event object retrieves all of it's information from the DB. If this is a web app, another approach (one I use a lot personally) would be to have the player object grab the event object from the web cache (and load the data/populate the cache) when needed. Anyway, I hope what I'm saying is coherent... -JB     Report

08-19-2005, 10:14 AM tbarcz Joined on 06-22-2005 Posts 44 Re: C# building classes/object This is for a Windows app....so web talk can cease here   Most likely, not all situations, but a majority, you'll want a cross section of information (Event Info with Player Info). The hybrid solution sounds nice, but it sounds a bit tricky (or rather unclear) on how to maintain.  Meaning if someone else picks up this code a year from now, it may not be clear at what I was doing (loading some variables when the object is loaded vs later for others).   thoughts?    Report

08-19-2005, 11:55 AM jbrunken Joined on 04-05-2005 Cedar Rapids Posts 66 Re: C# building classes/object Actually, you could do the same with a windows app by using a simple hashtable, but it may not make any sense in the context of a single user application... Anyway, I was afraid that my description was a bit vague.   It's a bit hard to describe without source code examples (which I don't have handy right now).   As far as maintainability goes, I think that's an issue of how you right the code itself more than the complexity of the solution.   If the code is well written (and :cough:  documented) even a complex solution should be fairly easy to understand.   On the flip side, I've seen (what should be) simple code that impossible to decipher/maintain. Below is one of many possible solutions to what I suggested... ----------------------- public class MyEvent {    private int _eventID;    private string _name;    private string _location;    private bool _isFullyPopulated = false;    /// Basic Constructor     public MyEvent(int eventID, string eventName)    {       _eventID = eventID;       _name = eventName;    }    /// Often used property    public string Name    {       get { return _name; }    }    /// Less used property    public string Location    {       get       {          if(_isFullyLoaded == false)          {             PopulateFromDB();          }          return _location;       }    }    private void PopulateFromDB()    {       ... Your DB code here       _isFullyLoaded = true;    }        }    Report

01-01-2006, 8:05 PM BillEvanson Joined on 10-09-2005 Solon Posts 5 Re: C# building classes/object Ok, classes modeling the database is fine when it make sense, but it your example it doesn't seem to make much sense.  Object vs relational design is a huge topic with many varying and valid opinions.  The Java world has bridged this topic before us (hibernate, etc.).  I wouldn't have an issue personally designing a class that represents a real world object in my application that persists its "state"  relationally in two or more database tables.  If you're really wanting to keep your classes modeled closely to your database, what about creating a view on the database and referencing the view from your code? Bill Evanson    Report

03-26-2008, 9:08 AM JackFlash Joined on 03-26-2008 Posts 1 Re: C# building classes/object What about PlayerEvent have a member of type Event, and when you submit the SQL to Database to retrive the informartion about PlayerEvent, you bring the information about Event too? IMO, I don't like the second alternative. Sounds that you are "mixing" two entities in one, and this may put you in trouble when you need to make a maintenance in this code...    Report

CRINETA » .NET Discussion... » Tips, Tricks & ... » Re: C# building classes/object

(please select) CRINETA Home |- Meetings |- About Us |- Member Blogs User Options |- Sign In |- Create a New Account |- Forgot Password Forums Home |- Search Forums |- Active Topics |- Unanswered Posts CRINETA Discussions |- CRINETA Announcements |-- Announcement Archive |- CRINETA Information |- CRINETA Topics & Presentations |- Chit-Chat .NET Discussions |- General .NET Discussions |- .NET Job Postings |- Tips, Tricks & Help: C# |- Tips, Tricks & Help: Visual Basic.NET |- Tips, Tricks & Help: ASP.NET |- Tips, Tricks & Help: WinForms