Re: paper on Prevayler

Karl Wettin <[email protected]> Wed, 6 Aug 2014 12:19:21 +0200
Newsgroups gmane.comp.java.prevayler
Message-ID <[email protected]>
On 06 Aug 2014, at 04:00, Justin Sampson <[email protected]> wrote:

> I'm surprised by Karl's comment that business logic inside a transaction is "horrible." Isn't that the whole point of Prevayler? That it allows you to do "real" OO programming, with business logic encapsulated in domain objects? It kind of defeats the purpose to push business logic back onto the client. Prevayler transactions are inherently fast, even with significant business logic, _because_ it's all in memory in a single process.

I suppose that the point of Prevayler is a matter of opinion, so don't focus to much on what I find horrible.

All I was trying to communicate is that I find short transactions to be spawns of leaving rules and calculations that decide how the domain data model is to be altered outside of the transaction, more or less making transactions clusters of setter properties. 

Actually, I never heard the terms short and long transactions before, but since I got comfortable with prevalence it's been my opinion for many reasons that one should chase the short. Afraid I have no time to go in to details about why right now, but to summarize it's about stuff such as loading large journals, debugging, speed of development and fixing bugs after the fact of executing my transactions. But if the only goal we consider is reaching a certain state of the prevalent object graph in order to achieve speedy read operations, then it really doesn't matter how we reach it. And that is why I say that I suppose that the point of Prevayler is a matter of opinion.


		kalle

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org