WF Foundation and LLBLGen - Good idea?

Posts   
 
    
Jeff M
User
Posts: 250
Joined: 04-Aug-2004
# Posted on: 17-May-2006 21:02:41   

The code examples that are provided with beta 2 rely on Transact-SQL for all persistence. The TrackingStore database (23 tables) has 70 stored procedures. A maintenance nightmare.

I'm thinking about porting the TrackingStore to LLBLGen objects which will allow me to eliminate virtually all of the stores procedures. I think that this will lead to much more maintainable code.

Good idea or waste of time? Anyone interested in this?

Jeff

DvK
User
Posts: 318
Joined: 22-Mar-2006
# Posted on: 17-May-2006 22:21:26   

Jeff,

For my understanding, the TrackingStore database is a fundamental part of WF ?

regards, Danny

Jeff M
User
Posts: 250
Joined: 04-Aug-2004
# Posted on: 17-May-2006 22:32:52   

DvK wrote:

Jeff,

For my understanding, the TrackingStore database is a fundamental part of WF ?

regards, Danny

Thus far, I can't determine whether that's true or not. I find it hard to believe that a framework would "hard-code" stored procedure calls.

Jeff

sparmar2000 avatar
Posts: 341
Joined: 30-Nov-2003
# Posted on: 18-May-2006 19:32:13   

Looking for it but failed to located it. Please can you help by supplying the URL?

Good idea or waste of time? Anyone interested in this?

BTW, I think its a brilient idea

Jeff M
User
Posts: 250
Joined: 04-Aug-2004
# Posted on: 18-May-2006 21:15:17   

sparmar2000 wrote:

Looking for it but failed to located it. Please can you help by supplying the URL?

http://www.windowsworkflow.net/default.aspx?tabindex=0&tabid=1

It appears that the stored procedure calls are hard-coded into the framework. No adapters, no nothing.

What a shame.

Jeff

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 19-May-2006 08:47:50   

What!?? Hardcoded? ieks! frowning

Frans Bouma | Lead developer LLBLGen Pro
jtgooding
User
Posts: 126
Joined: 26-Apr-2004
# Posted on: 19-May-2006 16:16:13   

Silly people, you simply need to make an LLBLPersist object using the base interfaces/classes. the SQLPersist class that comes with it is just an example and one that they will include, there is nothing that keeps you from writing your own persist engine.

The Portal people at MS have already created a DocPersist object that allows you to store the work flow in their document portal database as an example.

John

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 19-May-2006 21:19:25   

Thanks John, I already wondered how they (MS) could get away with this wink

Frans Bouma | Lead developer LLBLGen Pro
Jeff M
User
Posts: 250
Joined: 04-Aug-2004
# Posted on: 19-May-2006 22:11:11   

jtgooding wrote:

Silly people, you simply need to make an LLBLPersist object using the base interfaces/classes. the SQLPersist class that comes with it is just an example and one that they will include, there is nothing that keeps you from writing your own persist engine.

The Portal people at MS have already created a DocPersist object that allows you to store the work flow in their document portal database as an example.

John

ok. Found this: http://www.manuelfoerster.net/wordpress/40/ and this: http://blogs.msdn.com/moustafa/archive/2006/03/02/542459.aspx

So this is beginning to make some sense. However, I can't even begin to account for the 70 stored procedures and the 23 tables in the TrackingStore database. Nevertheless, I stand corrected on my previous statement regarding "hard-coding".

Jeff