SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Writing Nearly Codeless Apps: Part 1


Writing Nearly Codeless Apps: Part 1

Author
Message
Craig@Work
Craig@Work
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1354 Visits: 326
The trouble is though that the CRUD procedures auto-generated are effectively line-item procedures? i.e. the processing is done RBAR.

Creating procedures to do this, means effectively grinding through programming data into the database almost column-by-column, line by line.

I found the switch to TVPs very effective in stripping out so much procedural rubbish that imperative programming favours, and this encourages a much more intuitive style of programming in both C# components and in SQL itself.

Sure you need to have a SQL developer on hand to do this. But if you can have fewer C# coders as a result, what is the loss? Smile
kenambrose
kenambrose
Say Hey Kid
Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)Say Hey Kid (699 reputation)

Group: General Forum Members
Points: 699 Visits: 665
Hi,
And if you need more tsql programmers to compensate for less c# programmers, where is the gain?

In my opinion, *less* code is almost always a good thing - assuming it reduces complexity, maintenance costs, defects. Regardless of which tier the code lives on.

ken



Craig@Work
Craig@Work
Ten Centuries
Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)Ten Centuries (1.4K reputation)

Group: General Forum Members
Points: 1354 Visits: 326
Hi Ken,

I was perhaps trying to be provocative to make a serious point Smile

Re:- "In my opinion, *less* code is almost always a good thing - assuming it reduces complexity, maintenance costs, defects. Regardless of which tier the code lives on."

- Sure, who would disagree?

The thrust of my observation, is that by definition imperative programming languages (such as C#) almost force programmers (or rather lure?) them into micro-managing data, and decision making in software.

Having components that automatically write the SQL code is fine, provided that is really what is useful.

I tend to find that so many problems that are a pain to write in C#, are so much easier solved in SQL, provided you follow the 'natural' 'flow' and 'grain' of information.

The 'right' solution to a problem can very often be missed as organisations/managers/developers can say "We don't need to pay attention to what goes on in SQL, as we have this wonderful code-writing tool that writes our code for us".

My fear of taking this approach is that you end up with (bloated and) busy middle-tiers whiring and grinding round and round, and simply killing the associated SQL box with a barage of requests. This drives up hardware and licensing costs ("we won't write the code properly, just throw more application servers at the problem. SQL box dying? Get another bigger box. Data center suddenly not got enough power? Move to another one." etc.)

Of course, sometimes line-item approaches are best / absolutely required. It all depends on the nature of the system.
Milos Cigoj
Milos Cigoj
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 34
Great that somebody write about this stuff. We are practiceing this stuff even in a more advanced way since 2004 :-D. And it is very very useful and fast aproach.
DiegoPeña
DiegoPeña
SSC-Enthusiastic
SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)SSC-Enthusiastic (123 reputation)

Group: General Forum Members
Points: 123 Visits: 236
David Ziffer (10/6/2010)
timothyawiseman (10/6/2010)
I think it makes sense to decide, if not table by table, then certainly database by database whether you want to use artificial keys. I find the idea of standardized audit fields even worse since they do not make sense for all tables, and unused fields tend to create confusion and waste.

As to the comparison with the auto industry, I find it flawed. There the goal is precisely to mass produce large numbers of nearly identical products with interchangeable parts. It makes tremendous sense to standarize virtually everything in that and keep producing them. But no two software projects are absolutely identical (if they were, you would just copy the first one and be done with it).

Another thing to point out is that most assembly line workers are not the same as craftsmen. They just repeat the same thing over and over without trying to optimize for absolute performance. Software creation is much closer to that situation, then to assembly line workers repeating the same motions over and over.


Many good points here Timothy and let me respond to them. First with regards to artificial keys ... the whole point with RAP is to standardize the code generation and the ORM. I think it should be self-evident that one fantastic way to standardize and simplify an app is to have all the keys look exactly the same.

It would be way beyond the scope of this article and this blog for me to discuss all the benefits of using artificial keys, but let me focus on just one: you simply cannot audit a table that doesn't have one. Without an artificial key, there is no field in the table that guarantees continuity from one version of a row to the next (since business keys can always change). So artificial keys are critical to auditing.

Most people have never seen a 100% auditing application and so they can't imagine why you'd want to put status fields on every table. Well ... RAP produces 100% auditing apps. What this means is that you can actually log into your application "as of" a given date, and the app will open up with all of your data displayed as of that date. Screens, web pages, reports, everything. Even a web service, if that's what you're running. And that's just one advantage of having status fields in all tables. It's in the demo .. give it a try.

With regards to the auto analogy. Yes the analogy is flawed, because we are one level of abstraction higher here. With an auto assembly line the objective is to make a zillion of exactly the same thing. With RAP the objective is to make a zillion things whose underlying "plumbing" is built exactly the same way. A much better analogy would be the analogy to compilers, which use the same parameter-passing and code-generation techniques everywhere, but tailor them to whatever code you're writing.

But the automobile analogy is sexier.



Wow... so much wisdom in this...
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search