>
>So would a tool handle keeping my Stored Procedure structures consistent when I am returning the same object?>
>You could make a homegrown tool do anything you want it to do! <g> I don't know about any of the commercial tools, since I've never used any.
For some reason I'm just not grasping how this is going to solve my problem. I would have to make a tool recognize the fact that x,y, and z Stored Procedure's resultset should be the same structure. I'm not to the point of wanting to automate creation of anything yet, because honestly, my database/object structure isn't that complex.
My initial thought of having a View be the "master" structure of my objects, and a Stored Proc do a SELECT * would ensure they would return the same resultset structure. All I would have to do is open the view and see SELECT * FROM v_Customer WHERE .... and I would know that it would map to my customer object. The only red flag I see in that solution is using a SELECT * which I would have to learn to not cringe at. I was hoping somebody would just say "don't do that, dummy" and then I would forget about it. ;-)
>
>Hillsboro, Oregon? Is that new?>
>New as of the the 1st of October. It's a long story and will probably get even longer, but the abbreviated version is that we're still at the same company, but they wanted us to relocate. We still have our house in Ellensburg (in fact, we're "home" for the Thanksgiving holiday this week), and Tiburon is paying the rent on a furnished apartment in Hillsboro for up to 6 months while we do house-hunting there ... of course we all know about the housing market right now. =0(
>
>~~Bonnie
Good luck with that!
>>
>>>Mike -- I just wanted to second what Paul said about using a tool for this ... either store-bought <g> or homegrown. We use a homegrown tool ... it started out very simple in the early days (similar to Paul's ... we'd just give it a Stored Proc name and it would generate our class, which in our case was simply an .xsd). Now the tool has been tweaked to do a whole bunch of other stuff besides this and I don't even know what it's doing anymore, it got really complicated (I'm not in charge of it).
>>>
>>>~~Bonnie
>>>
>>>
>>>
>>>>>>Trying to map all of my Select Stored Procs to the same Business Object is getting tough. I had hoped other developers would offer their methods to make sure the structure stays in sync.
>>>>>>
>>>>>>Thanks for the reply. I think it's a good idea and was looking for somebody to either raise a red flag or say it was a good idea. Thanks!
>>>>>
>>>>>I think a lot of us are using various tools like Codesmith, My Generation, homegrown, etc. to build our Entities for us automatically. Essentially the tool calls and/or looks at a given table/view/stored proc. then builds the wrapper class based off of it.
>>>>>
>>>>>Most of my stored procs. where I do this map fairly reasonably onto an existing entity built from my tables (that is, the stored proc. returns a subset or superset of the table). I've been pretty lazy so far - in the few cases where I wanted strongly typed access to those additional fields, I just manually added the code. In most other cases I just fall back to accessing them via table.Rows[0]["RowName" style syntax. Ugly but it doesn't seem to come up that often in the stuff I've been working on.
>>>>
>>>>I see. Thanks for the input.
