Database development
in [Java Programming]
|
Prev: Null pointer issues
Next: Urgent
From: Pitch on 28 Apr 2010 04:52 In article <4bd79011$0$284$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk says... > > On 27-04-2010 04:54, Pitch wrote: > > In article<hr3r1v$bvp$2(a)news.albasani.net>, noone(a)lewscanon.com says... > >> junw2000(a)gmail.com says... > >>>> When I work on database development projects, I use JDBC and SQL. Many > >>>> people use hibernate/spring. Can somebody explain the pros and cons of > >>>> using JDBC and SQL vs using hibernate/spring on database > >>>> developments? > >> > >> Pitch wrote: > >>> I always believed that ORM systems are forcing you to write your own > >>> business-rules layer apart from the persistence layer. That way database > >>> access is kept simple and easy mantainable. > >> > >> ORM doesn't force business rules into a separate layer and raw JDBC calls > >> don't force them into the same layer as persistence. > > > > I disagree. > > Can you explain what prevents you from copying business logic and > for that matter presentation logic into Hibernate/JPA data classes? > > Arne experience -- stirr your cofee properly
From: Gunter Herrmann on 28 Apr 2010 07:20 Hi! Robert Klemme wrote: > Btw, did I mention that I believe database independence is a myth? :-) If you want to write code that runs on "all" databases, you cannot use any of the special features of any database. Your code will run (rather crawl) on every database. If you want a fast application let the database do what it can do best, and create an API on top of it. In case your back end runs on Oracle, use packaged stored procedures, table functions, pipelined functions. This way you make sure that different programs (written in different programming languages) are all controlled by the same database code. If you did this from the start you can easily have - Oracle forms - Cold fusion - a Java desktop application - an interface for processing remote requests (written in C) - another interface for processing remote requests (written in Pascal) - ... do the same thing without messing up the data. You can encapsulate the tables behind this by only giving execute privs on the API procedures to all the clients. No insert/update/delete privs for any client software. This way you can easily change the client without rewriting the logic. brgds Gunter, Orlando, Fla.
From: Tom Anderson on 28 Apr 2010 08:49 On Tue, 27 Apr 2010, Arne Vajh?j wrote: > On 27-04-2010 15:10, Tom Anderson wrote: >> On Mon, 26 Apr 2010, Arne Vajh?j wrote: >> >>> My preference is: if database need to be accessed by apps in different >>> technology, then it makes sense to put the business logic in SP's - >>> otherwise I would keep the business logic in the Java code, because >>> that makes it a lot cheaper to work with a different database - >> >> It's worth mentioning that the modern alternative approach here is to >> put hide the database completely behind the java, and expose the >> functionality through web services. Rather than having other apps talk >> to the database directly, they make calls to the java layer. That lets >> you raise the level of abstraction in the other apps, reuse >> functionality in the java, and maintain the invariants enforced by the >> business logic in the java. > > Modern alternative???? > > I thought it was a classic anti-pattern to expose DAL as services > instead of BLL as services. Yes. Sorry if i didn't make it clear enough, but i was talking about exposing domain-model operations, not raw database operations. Hence the bit about "That lets you raise the level of abstraction in the other apps, reuse functionality in the java, and maintain the invariants enforced by the business logic in the java.". And the paragraph discussing the fact that developing other apps will involve adding business logic to the java. tom -- IMPORTANCE MEMO: >>> WHEN YOU BUY AN N-GAGE QD <<< PLEASE, please CONTINUE TO TALK ON THE SIDE!!$ Note: the other party will not be able to hear you, BUT WHO REALLY CRAPS A THING, SIDETALKIN' 2009++!!!
From: Lew on 28 Apr 2010 20:06 Lew wrote: >>>> ORM doesn't force business rules into a separate layer and raw JDBC calls >>>> don't force them into the same layer as persistence. Pitch wrote: >>> I disagree. Arne Vajhøj wrote: >> Can you explain what prevents you from copying business logic and >> for that matter presentation logic into Hibernate/JPA data classes? Pitch wrote: > experience You just proved that the ORM is not what forces business rules into a separate layer, confirming my claim. -- Lew
From: Arne Vajhøj on 28 Apr 2010 21:56
On 28-04-2010 04:52, Pitch wrote: > In article<4bd79011$0$284$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk > says... >> On 27-04-2010 04:54, Pitch wrote: >>> In article<hr3r1v$bvp$2(a)news.albasani.net>, noone(a)lewscanon.com says... >>>> junw2000(a)gmail.com says... >>>>>> When I work on database development projects, I use JDBC and SQL. Many >>>>>> people use hibernate/spring. Can somebody explain the pros and cons of >>>>>> using JDBC and SQL vs using hibernate/spring on database >>>>>> developments? >>>> >>>> Pitch wrote: >>>>> I always believed that ORM systems are forcing you to write your own >>>>> business-rules layer apart from the persistence layer. That way database >>>>> access is kept simple and easy mantainable. >>>> >>>> ORM doesn't force business rules into a separate layer and raw JDBC calls >>>> don't force them into the same layer as persistence. >>> >>> I disagree. >> >> Can you explain what prevents you from copying business logic and >> for that matter presentation logic into Hibernate/JPA data classes? > > experience Well - ORM implementations does not carry experience AI into the app. And your experience is not part of the ORM. Arne |