Adding a child to a collection that needs data from the DB when creating it?

pgroenenstein posted on Wednesday, September 16, 2009

How does one add a new child to the collection that needs to be populated by data from the DB?

The example in the book DOES NOT show how to add a child that needs to get some data from the DB when adding it to the collection. Basically I want to add a "Product" to a invoice when the user clicks on a button on the screen.

ajj3085 replied on Wednesday, September 16, 2009

I do this by having the line item factory method accept a ProductInfo RO object.

Of course, this means you can't use the AddNew method, but you can call the Add method on the BindingSource which is tied to your LineItems collection.

pgroenenstein replied on Wednesday, September 16, 2009

Probably need to go that route, Why does the Child_create even exist? The child should be able to be created by reading from the DB base.

It seems to me that CSLA.Net is a step backwards from old CSLA(which i'm used to), one loses the freedom on how to code the way you like.

Forcing me to only use certain "CRUD" methods is not cool!!!! When adding a "Item" to a collection the info I get from the DB is vastly different from when just normally load the object from "Fetch".

I can understand now why a lot of people on the net is "bad mouthing" CSLA.Net. I do think it is a GREAT framework. But lets be honest the sample is NO WHERE close to being adequte (unless maybe you where in it from the start). The sample DOES NOT cover even the most common of scenarios you might run into. (e.g. adding a item from the db to a collection [And I don't mean "loading it" I mean "add new Item" also "Finalising a document {Way different from saving it})

Tom_W replied on Wednesday, September 16, 2009

I'm probably misunderstanding what you're trying to do here, but if the aim is to use default values from the database to populate a new instance of a child object then you need to add a DataPortal_Create method (like an Editable Root) and call DataPortal.Create() in your NewEditableChild() method.  You also need to set MarkAsChild() in DataPortal_Create(). 

(Details of this are in Chapter 5, section 'Loading Default Values from a Data Store').

pgroenenstein replied on Wednesday, September 16, 2009

Hi Tom_W

I did go with "dataportal_create" it works fine, my MISTAKE was using the childcreate bit. All sorted now.

Looked at Chapter 5 also, the book is not as good organised as Rocky's previous books I think. I understand that he needed to cram a lot of info in there but I think some areas could have been more informative. Maybe what is needed is a sort of "Quick Start" guide because in a hurry it is hard to read all the stuff. Also the sample app's zip files does not really match the documentation, so when unzipping it there is a lot to figure out before you can fire her up. It all adds to the confusion. I LOVE CSLA but now I need to get up to speed on CSLA.Net...not so easy. But I will stick it out and should have it all under wraps soon, but someone that is looking at CSLA.NET to evaluate it wouls very easily just throw his or hers hands up in the air and waolk away form it all(bad mouthing it as they go, sad but true).

Tom_W replied on Wednesday, September 16, 2009

Glad you got it sorted

Re your other points:  As someone who is fairly new to CSLA and still going up the learning curve I agree with you.  I have posted on this before and I know Rocky is trying to address this with the video series - I think there is a WinForms version of the videos coming too at some point?

The lack of a fully worked best practice example is the single biggest issue to my mind though; I've lost count of the number of times over the last few months that I have been pulling my hair out trying to do something really basic.  I know that every problem needs an appropriate solution, and that this should be well thought out etc., and that one example app will not fit all scenarios, but at the end of the day we are a business, a solution now is better than the perfect solution too late!

We actually originally looked at CSLA a couple of years ago, found the learning curve too steep and ended up cobbling together a highly inferior in-house framework of our own.  Only later, once we spent months ironing out all the hidden problems of data-binding etc did we realise just how good CSLA was, and at that point we took the decision as a company to switch to CSLA.

I'm glad we made that choice, but I would happily pay for training (unfortunately not available in the UK) and for a fully worked up example app - that would save us thousands of pounds in the long term.  The next best solution we are going for is to try and recruit an experienced CSLA contractor to work on our current project and hopefully teach us something along the way.  Is that an approach you could try?

Sorry, that turned into a bit of a ramble.. not having a go at Rocky or anyone else obviously, and I hugely appreciate the dedication that allows CSLA to exist at all, but I do agree with you that CSLA adoption is actually probably a lot less than it could be for the reasons above - adopting CSLA is a much harder business case to make than it really needs to be.

pgroenenstein replied on Wednesday, September 16, 2009

I FULLY support CSLA and appreciate what Rocky did for it, I would recommend it to one and all to use, since I used CSLA VB6 for many years and it is EXTREMLY STABLE!. The FRUSTRATION from CSLA.NET stems from the learning curve! Other than that I trust it would be even better than CSLA VB6, as I see a lot of the plumbing is now taken out of the way of the programmer and nicely tucked into CSLA.DLL.

ajj3085 replied on Wednesday, September 16, 2009

Well you can do that.. Child_Create is useful if you're creating a child object with some default values when you're also creating a new root object. So if your use case is that when you create a new invoice you automatically get some line items already added (why you'd want that, I don't know). If you create line item instance AFTER you're new invoice is already on the client, then your line item class should implement DataPortal_Create, which will allow you to load from the database because you know you're running on the server. You don't NEED to pass a RO object to load from... that's MY preference... why go to the database AGAIN when I've already hit it to get the product data to display to the user? So I have it read from the RO object, and mark my DataPortal_Create with a [RunLocal] to avoid an unnessary network hop.

pgroenenstein:

It seems to me that CSLA.Net is a step backwards from old CSLA(which i'm used to), one loses the freedom on how to code the way you like.

I've seen the old vb6 code, and Rocky in the book explains why he changed things.. in reality VB6 forced him to build that version a certain way, because in the oringal C# csla book I think there's a comment that .net enabled for the first time proper OO design.

And yes, like any framework, you need to do things a certain way to take advantage of it. And this is a good thing; loss of freedom means you have more structured, maintainable code, which is one of the reasons to use Csla in the first place. A clean seperation of concerns.

pgroenenstein:

Forcing me to only use certain "CRUD" methods is not cool!!!! When adding a "Item" to a collection the info I get from the DB is vastly different from when just normally load the object from "Fetch".

How so? At any rate, you CAN get the object to load from the database.

:

I can understand now why a lot of people on the net is "bad mouthing" CSLA.Net. I do think it is a GREAT framework. But lets be honest the sample is NO WHERE close to being adequte (unless maybe you where in it from the start). The sample DOES NOT cover even the most common of scenarios you might run into. (e.g. adding a item from the db to a collection [And I don't mean "loading it" I mean "add new Item" also "Finalising a document {Way different from saving it})

Only if you don't buy into the philosophy the framework is built on. But many people have great success using csla. Most people badmouthing it completely fail to understand the gap its trying to fill. They view Csla as a ORM. Its not an ORM, that's not why you'd use it. Its a Business object framework. This sounds like the boat you're in.

I suggest you read chapters 1 - 3 of the book to get an understanding of what the framework is and what it isn't.

I find your last comment particually amusing, because I built an application which deals with invoices, line items, finalizing (closing in my users terminiology) and converting documents (quotes to orders to invoices).. all on Csla.

Finalizing is more than just saving... and Csla handles this just fine. One method is to make the DataPortal_Update include the extra code to finalize based on some flag... another (better, IMO) way is to have a class which does only that... finalizes the invoice... I'd call it InvoiceFinalizer... much like I have an OrderConverter, InvoiceConverter, etc. It works rather well, but you need to buy into the philosophy behind the framework. And again IMO, you'll be a much happier business application coder if you choose to do so.

Oh, sorry to Rocky for stealing most of the points :-)

pgroenenstein replied on Wednesday, September 16, 2009

HI ajj3085

I needed to add a item after the invoice is already on the client. Got it sorted now MY Mistake in using Child Create for it first time around.

One "CRUD" method that is missing is a "Finalise" method. It would have been a lot easier if such a option did exist, cause "Saving" and "Loading" a invoice is perfectly fine while it is still a draft invoice...but a lot of documents (e.g. an invoice) has a case where the "draft" get's "finalised", in other words it becomes an "invoice" once this method is called. "Real world" scenarios indicates that what happens to a invoice when being "Finalise" is vastly different from a draft being "SAVED". A "CRUD" method that you can "use as you please" would have been a nice inclusion here.

I totally buy into the philosophy of the framework, "Better Samples" would have been a MAJOR advantage as I think most of us learn by example rather than from "Studying"

I do understand the framework as I come from CSLA VB6 and have a VERY LARGE program which a lot of different kinds of documents being used.

To use the "DataPortal_Update" with a flag is not cool. Since what about a "draft" that was "saved" then "loaded" again without changing SOME of the lines. In effect that means certain lines would be neither "Dirty" nor "New", so if I call "UPDATE" some lines would not be committed (I have a way around that now) unless you mess with the "flags" and set then to a "Dirty" or "New" status.....Not Good if you ask me. One should leave the flags to CSLA to manage and not "Manually" Force them.

I LIKE CSLA A LOT AND PERSONALLY AGREE that it is a vastly SUPERIOR framework, BUT o boy..THE LEARNING CURVE is STEEP, more so if it has to be cramp into a couple of weeks. Maybe old habits dies hard, but being use to CSLA VB6 might be part of the problem. I TOTALLY DISAGREE with the guys "bad mouthing" CSLA, I think it is due to them not really understanding the philosophy of the framework. My point is this: I can UNDERSTAND (not saying I'm agreeing with them) why some people "bad mouths" it, More COMPLETE sample code would go a long way in geting rid of the misunderstanding.

Quote : "I find your last comment particually amusing, because I built an application which deals with invoices, line items, finalizing (closing in my users terminiology) and converting documents (quotes to orders to invoices).. all on Csla."
I have it all to..it is just not so easy to figure out first time around!, but I'm well on my way figuring it all out!


Kind Regards.

ajj3085 replied on Wednesday, September 16, 2009

Glad you got it all sorted out.

If your Finalize is complicated enough, I would go the route I mentioned before and work on a FinalizeInvoice, which would subclasss CommandBase. You can even hide this class if you like and have a Finalize method on your invoice which calls the command and examines the result.

Maybe that would make more sense to you even if finalizing is pretty straightforward. Sometimes its just conceptually easier to do things that way, and you're right it would make the DP_U code cleaner since there's no branching based on a flag. But it all depends on the use case.

Sorry about getting a bit defensive, I guess I mistook your frustration as bashing. While your problem is the learning curve (and I'll grant you its fairly steep), many don't even get as far as you into Csla before the bashing starts.. and as I said, its usually because of a failure to grasp the purpose of the framework. Anyway I do appologize if I was a bit harsh.

I don't envy your position; in building my quoting / invoicing module, the business rules around that were enough without having to learn csla... but even then, I STILL had more learning to do on Csla (and still do, probably..). It was similarlly complex functionality that I was trying for when I posted here, and Rocky gave me the advice that my converters should be classes of their own. Such a simple thing that I would have never thought of, and once I "got it" it made coding those requirements so much simplier.

I do hope you've taken the time to learn the "managed properties" concept... they save you so much code (and time) its well worth it.

Good luck, and post back if you have any other issues, this is a great forum and I know you and I aren't the only ones here who have tackled use cases involving invoices and quotes!

Tom_W replied on Wednesday, September 16, 2009

ajj3085:

I know you and I aren't the only ones here who have tackled use cases involving invoices and quotes!

Do you ever wonder how many man hours have been spent by how many people since the dawn of computing writing db tables, sprocs and classes for customer, supplier, quotes, sales orders, invoices etc... just a thought!

pgroenenstein replied on Wednesday, September 16, 2009

Apologies accepted...I must admit my post sounded a lot like a bashing, sorry for that.

As far as managed properties is concerned, it sure is a MAJOR step forward by taking ALL those plumbing away. In that regard I think Rocky has hit his target of simplifying the BO just about 100%, and congrats to him would be in order.

My "Finalize" is not complex at all, just different from "Update" but still I would go for the "CommandBase" option as I believe that would result in code that would be easier to maintain.

Coming from CSLA VB6 I can see that A LOT of the shortcomings were addressed, and I for one are happy about that.

Once you have the "Remoting" going and the parts of the plumbing that unfortunately has to be around, it is a piece of cake to code.

CSLA.Net surely is the framework to use if you are interest in RAPID development without compromising reliability and/or maintainability.

Thanks for your input and kind regards.