Most of my experience are working with winforms now my new job are more on web apps and I decided to go for ASP.NET 2.0 and CSLA 2.0 ..
When enabling Edit, Update and Cancel and Delete commands using GridView in ASP.NET it display a hyperlink edit and delete each row. It means you can edit / delete a row one at a time.
Given:
My plan is to use ReadOnlyListBase for listing it in the gridview and using the business object in #1 for editing/deleting over BusinessListBase.
Am I right with my plan? Any suggestions?
P.S. I'll read your replies tomorrow 05/06/2006. cause its 4:28am dawn here in Phil. Cebu
I've thought that, for this type of scenario, having a new collection type wouldn't be all bad. Something like LiveListBase - because the list would be "live" against the data store.
This class would inherit from List<T> and would implement only DataPortal_Fetch().
<Serializable()> _
Similarly there'd be a Remove() overload so when a child is removed from the collection it is automatically removed from the data store:
Public Overloads Sub Remove(ByVal child As C)I haven't tried this, so there may be unforseen issues, but it seems like an easy thing to do to support the atomic add/remove scenarios for the web (and maybe for some types of Windows app too).
I see.. you really ROCKS Rocky. But right now, I stick on the ReadOnlyListBase w/ BusinessBase but I'll do my research and testing on your suggestion and post it back here later if I'm done with it. Thanks for your info I'll try to look at this if it is feasible in my scenario.
Doing web apps is very different compared doing win apps. In my own perspective it has many things to considered like when to store a set of data in a session or just retrieved back from its datas source during post backs because we want to achieve realtime information.
In my case, I didn't store the ReadOnlyList in the session I just let it retrieved it back from the datasource for the reason it might be too large to store in a session if the result of the DataPortal_Fetch() is big also.
I dont know if this is the professional way of doing it, but this is how I did:
Given:
BookList - Is the ReadOnyListBase (implemented as Root)
BookListInfo - Is the a ReadOnlyBase (that only implements 6 properties)
My reason for doing this is that I dont need to implement those fields that will not be used in the ReadOnlyList.
Book - Is the BusinessBase object (implemented as Root) and implements 20 properties
The said 3 fields that will be edited doesn't have business rules.
The big question with the web is whether you can use state on the web server or not. If you can, then it doesn't have to be much different from Windows. But if you can't, then you need to artificially alter your object model to compensate for the constraints of the web - which complicates things.
Specifically, if you are going to be stateless then resign yourself to only having editable root objects, and collections of editable root objects. Resign yourself to manually coding to detect things like duplicate child data, or summarized data on parent objects. You have to manually code these things, because you won't have actual parent-child object relationships (which would have automatically handled most of the business rules).
In short, writing a stateless object model is more complex and thus more expensive than a stateful one, because you lose the abiltity to take advantage of relationships between objects. However, it can certainly be done, and must be done for some higher-volume web sites.
Copyright (c) Marimer LLC