"It's the least worst response to a bad situation - not having
business logic close to the database. It's more to test, develop, deploy and
change control. And to be successful it still needs to call stored
procedures at the back end.And to be successful it still needs to call
stored procedures at the back end."

Really?  I've worked on lots of successful products that didn't use stored
procedures at the back end.

Again, it doesn't matter where the code is *physically*.  What is this
"close to the database" catch phrase *really* mean anyway?  Are you talking
about speed?  I have to image you see some benefit, because IMHO you're
giving up a lot of flexibility by writing your business rules in stored
procedure languages like UniBasic and TSQL.  I'd also argue that having code
live with the database can make the application as a whole far less portable
as you scatter code around.  More moving parts is generally a bad thing.

Yes, you should tier your code and keep your business logic separate from
your presentation layer, but that doesn't mean it literally needs to be in a
stored procedure.  Look at the MVC pattern in Rails or ASP.NET MVC, for
instance.  In those frameworks, all of the business logic lives in model
classes in the main application, not the database.  It works really well --
if it didn't, people would break that mold and start putting code in sprocs.

-Rob

On Thu, Jul 14, 2011 at 3:41 PM, Brian Leach <br...@brianleach.co.uk> wrote:

> I've missed this discussion because I've been busy designing a website and
> app for a client.
>
> This being the real world, the site will eventually - of course - be
> delivered using SQL Server and C#, with the front end using AJAX calls to
> JSON services delivered through WCF. Which will no doubt take an age to
> develop, test, deploy and then reconfigure all over all again.
>
> So before getting to that stage, I've written a fully functioning
> prototype.
> Which is - of course - written in UniVerse and mvScript. Which means I've
> developed it all front to back in a few hours and it's robust and flexible
> enough that I can work through it sitting with the clients tomorrow and
> make
> changes in near real time as they come up with ideas.
>
> Which tells the story, in one, of what I do and don't like about U2.
>
>
> As to some of the other points:
>
> 1. Someone mentioned SQL Server and the GUI word again. Please ... SQL
> Server has no UI. If you're coding a UI for SQL server you use C#. If
> you're
> coding a UI for U2 you can use C#. If you're coding business rules for SQL
> Server you can use SQL Manager. If you're coding business rules for U2 you
> can use BDT or mvDeveloper. It's a red herring.
>
> 2. The other thread has been talking about locking. If there's one reason
> to
> use U2 over all else, it's pessimistic locking. The SQL world is full of
> script kiddies and wizard users who *think* they know SQL and don't have
> the
> first idea about concurrency, locking and merging.
>
> 3. Yes, we now have CLR in SQL server, but how many SQL developers are
> actually using it? The initial push to add it was a horrible cludge and put
> off many of those who might have experimented, and for the rest of the
> community it's too alien. I think we'll see TSQL as the main language for
> back end work for a long, long time - and that doesn't begin to measure up
> to UniBasic. (but read on before you jump on this...)
>
> 4. Having middle tier logic may be the norm but that does not mean it a
> good
> idea. It's the least worst response to a bad situation - not having
> business
> logic close to the database. It's more to test, develop, deploy and change
> control. And to be successful it still needs to call stored procedures at
> the back end.
>
> 5. But if you really want a middle tier, you can still add one and use C#
> and it's 'proper libraries' with U2. If you really, really want.
>
> 6. And either way, not having to stare at query optimizer output is a very
> good reason to like U2.
>
> BUT
>
> That doesn't mean U2 can't be improved by taking on some of the better
> features of the outside world.
>
> The indexing is still very primitive, the SQL support is weak, and it would
> be great to have some other languages built into the database runtime. Even
> java - <shudder> - would be better than nothing, and would provide those
> 'missing' OO and library features that people think they want.
>
> Add OpenQM's version of objects into Basic while you're at it and make the
> Basic on the two products more similar. It's just a pain having to use two
> sets of syntax: Rocket could easily create a superset on both.
>
> Nowadays you can at least integrate the query and Basic language by using
> SQLExecute() function calls to @HSTMT - something that was always missing
> from the original Pick model. But it's not obvious and doesn't work from
> phantoms.
>
> For the client side, we need javascript bindings made easy - especially to
> JSON - as that is the most important language for new developers today.
> Look
> at all the new development platforms like Titanium that are built on top of
> it or that compile down from it.
>
> Just publishing the UniRPC protocol would be another good start, then
> developers could write native binding in other socket-supporting languages.
> Oh sorry - I've been asking for that for about a decade.
>
> Linking to a distributed memory cache - like Oracle does with Coherence
> (which it took as an open source product) - to give linear scalability and
> failover. Temporary tables for workfiles, in memory and/or reserved per
> session and cleared down on session end. Hint - per-session means no impact
> on the lock table for concurrency or for extension.
>
> And get rid of Eclipse. It's horrible.
>
> And from the commercial angle - produce a version that get can entice
> people
> into the product at the bottom level, with limits that will constrain it
> but
> an upgrade path to the full version as the usage grows and the business
> benefit becomes clear - like MS does with SQL Express. Allow developers to
> redistribute it. And make it appealing for web development. Right now it's
> not, whilst the charging model is still on a per-user and additional
> connection pooling basis: that puts it out of scope for those zillions of
> sites that need cheap lightweight data sourcing.
>
> My 2c.
>
>
> Brian
>
>
>
> _______________________________________________
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to