Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««56789

Writing Nearly Codeless Apps: Part 1 Expand / Collapse
Author
Message
Posted Wednesday, October 20, 2010 3:38 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, June 5, 2014 6:18 AM
Points: 1,140, 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? :)
Post #1007551
Posted Wednesday, October 20, 2010 9:53 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 3:30 PM
Points: 71, Visits: 479
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



Post #1007844
Posted Wednesday, October 20, 2010 10:56 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, June 5, 2014 6:18 AM
Points: 1,140, Visits: 326
Hi Ken,

I was perhaps trying to be provocative to make a serious point :)

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.
Post #1007884
Posted Wednesday, October 27, 2010 1:22 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, July 15, 2013 6:36 AM
Points: 1, Visits: 34
Great that somebody write about this stuff. We are practiceing this stuff even in a more advanced way since 2004 . And it is very very useful and fast aproach.
Post #1011304
Posted Wednesday, December 28, 2011 7:30 AM


SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, July 21, 2014 8:44 AM
Points: 39, Visits: 192
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...
Post #1227350
« Prev Topic | Next Topic »

Add to briefcase «««56789

Permissions Expand / Collapse