WHERE
[quot_int_ID] = @quot_int_ID
--Load related QuoteLineItem records
Select
[item_int_ID],
[item_int_Column1],
[item_int_Column2],
[item_int_Column3]
from Item
where item_quot_int_id = @quot_int_ID
Private Overloads Sub DataPortal_Fetch(ByVal objCriteria As Criteria)
Dim tr As SqlTransaction
Using cn As SqlConnection = New SqlConnection(Database.Contest03UKConnection)
cn.Open()
tr = cn.BeginTransaction()
Try
Using cm As SqlCommand = tr.Connection.CreateCommand()
cm.Transaction = tr
cm.CommandType = CommandType.StoredProcedure
cm.CommandText = "sprQuote_Select_CSLA"
cm.Parameters.AddWithValue("@quot_int_ID", objCriteria.ID)
Using dr As SafeDataReader = New SafeDataReader(cm.ExecuteReader())
dr.Read()
‘load object from dr
ValidationRules.CheckRules()
'load child object(s)
dr.NextResult()
m_objItem_List = clsQuoteListItemCollection.QuoteListItemCollection(dr)
End Using
End Using
tr.Commit()
Catch
tr.Rollback()
Throw
End Try
End Using
End Sub
RockfordLhotka replied on Friday, January 12, 2007
TerryHolland:
My concerns are that when loading a quote, Im loading a lot of related data which is not immediately necessary, that may cause a memory problem with the number of concurrent users.
Your objects should be designed around your use cases, not around your data. What you've described thus far are a set of objects that map 1:1 to your tables (pretty much anyway), but it sounds like that is a mismatch when compared to your application's usage.
I say this because of your concern. You seem to be indicating that there are tasks the user is performing that don't require all the data in that huge object graph. Those tasks are, effectively, use cases. It is most certainly true that each use case should have its own object model: designed specifically to accomodate that use case.
So it is highly unlikely, especially in a web setting (which it sounds like where you are) that you'd have such a comprehensive object graph. That might make sense in a WinForms setting, where you really could have a form that displays and edits all that data at once. But in the web that's just not likely.
Odds are that your object model is not 1:1 with the database. Rather, it may be 3:1 - 3 objects per table, with each object filling a different role based on a different use case. The focus isn't on the data though, but rather on the behavior required by the use case.
You have a use case where the user brings up a quote, with a list of read-only line items. That makes sense, and you should have an object model FOR THIS USE CASE that reflects this need. Probably
Quote<-ReadOnlyRoot
ItemList<-ReadOnlyChildList
Item<-ReadOnlyChild
Then it sounds like you have a case where the user wants to edit one of the line items. That's a use case, with its own object(s), probably:
QuoteItem<-EditableRoot
Again, in a WinForms setting the object model could be factored at a higher level. And for many web scenarios you don't need this level of breakdown either. But if you are building a high volume web site where you have hundreds of concurrent users hitting your web site, you probably do need to do a design at this level of granularity (where each page (more or less) is considered a use case.
I don't know if you really do have that kind of scalability requirement or not - most people don't.
When thinking about server memory consumption it is important to be clear about what's going on. Objects are only as big (in memory) as the size of their instance fields. That's it.
However, you are talking about ~12000 objects in your graph. So for fun, let's say they average 150 bytes of data per object - that's nearly 2 meg per graph (per user). If you only have 10 or 20 users, that should be a non-issue. 200 users becomes an issue ![Smile [:)]](/emoticons/emotion-1.gif)
On the other hand, rationally thinking about it, can a user actually interact with 12000 objects in any meaningful sense? That seems quite unlikely - even in a WinForms setting.
So far the idea of this mega-object-graph is not passing any sort of sniff test (for me anyway) - web or Windows aside.
So perhaps you consider that at a broader level you have these use cases:
- List quotes
- Display a quote
- Edit a quote
- Edit a line item
- Edit stock items
- Edit labor items
Odds are this set of use cases is consistent across web or Windows. And each one of these use cases will have its own set of objects. DON'T TRY TO REUSE THEM in your initial designs. Just design each use case independantly (use Chapter 6 as a guide). When you are done, THEN you can see if reuse is possible or desirable.
Certainly any consistent business rules (rule methods) should be candidates for reuse. But DO NOT reuse just because there are common properties. Property code is meaningless - template/snippet stuff, not worthy of reuse. But algorithmic logic or validation logic - that is good for reuse.
And you might have certain name-value lists or other read-only data objects that appear in multiple use cases - that's quite common.
But I wouldn't expect to see your mainline business objects span these use cases. Each one of these use cases addresses a different need, and will almost certainly have its own set of objects.
TerryHolland replied on Saturday, January 13, 2007
RockfordLhotka:
So it is highly unlikely, especially in a web setting (which it sounds like where you are) that you'd have such a comprehensive object graph. That might make sense in a WinForms setting, where you really could have a form that displays and edits all that data at once. But in the web that's just not likely.
So does this imply that you would use a different set of business objects for a web app to those that you would use for a win app? Some of my application will be used in a win application as well as web - though 80% of app will be a web app
RockfordLhotka:
Quote<-ReadOnlyRoot
ItemList<-ReadOnlyChildList
Item<-ReadOnlyChild
Then it sounds like you have a case where the user wants to edit one of the line items. That's a use case, with its own object(s), probably:
QuoteItem<-EditableRoot
It seems from what you are saying, that there is not much need for EditableChildList or EditableChild classes in a web environment. That being the case would it not be better to use ReadOnlyRootList and ReadOnlyRoot classes for my list of QuoteItems that will display on my Quote page. This way, if when I added an Item for example, in a pop-up window, I could easily refresh the list of QuoteItems without having to reload the Quote object when pop-up is closed and focus is back on the Quote page if I use Ajax technology on my QuoteItems list
RockfordLhotka:
On the other hand, rationally thinking about it, can a user actually interact with 12000 objects in any meaningful sense? That seems quite unlikely - even in a WinForms setting.
You're absolutely right - this is not necessary.
Thanks again for your input
SonOfPirate replied on Saturday, January 13, 2007
Fact is that Win apps will support the more complex object models but that doesn't mean that you have to use them. I have found that following the more web-oriented approach still works well for Win apps. In fact, it allows you to decouple your forms from each other which, IMO, is a better and more flexible design.
In my experience, although I don't use it much, EditableChildList and EditableChild can come into play in web apps when you want to have an editable grid (i.e. inline editing).
As for your question about adding items to the child collections, it sounds like you are on the right track. Since the child object (QuoteItem) is being edited in another form, it is persisted to the data store from that form so all you have to do is refresh the original to reflect the changes. As far as the underlying mechanics since the QuoteItems collection is derived from ReadOnlyChildList, well... You never really have to add it to the collection, do you? That's the trick.
By persisting the child object to the data store itself then refreshing the QuoteItems collection from the same data store, you have the same affect without having to code the addition. Make sense? This is divergent from the way we are used to thinking and is something I struggled to wrap my head around originally, but it works and simplifies things greatly.
This is different, of course, to many-to-many relationships where you do have to establish that relationship somewhere. Rocky illustrates this with the Project->ProjectResource->Resource, etc. design in his ProjectTracker sample project.
Good luck. HTH
