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 ««12345»»»

Writing Nearly Codeless Apps: Part 2 Expand / Collapse
Author
Message
Posted Wednesday, October 13, 2010 8:58 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
richardd (10/13/2010)
[quoteIf that's the case then your database design sucks. If there's a table called "Customers", why would there ever be a view called "Customers" in the same schema? It's pointless and confusing.


It is entirely possible that an application would want to have consistent views of essentially all its tables that exclude things like status fields. So if I have an app where I need an entire set of views that correspond to essentially all the tables, I'd have to distinguish their names somehow. Better to do it consistently than inconsistently.

Beyond this there is a practical example that RAP actually uses (this is explained two or three articles down the road BTW). For every single primary key, foreign key, and unique constraint or index in each table, RAP generates a set of user-functions and a corresponding set of stored procedures that allow you to look up records in the table according to the fields of that key or index. The user functions are intended for use in any hand-written queries you may want to write (primarily for reports), whereas the stored procedures are intended for use by the application's data layer.

The user function and the corresponding stored procedure are identical except that one is a user function and the other is a stored procedure. So there's a choice here: invent some algorithm for inconsistently modifying the generated names of otherwise identical objects, or simply have a consistent naming convention for distinguishing them. RAP is all about consistency, so it uses the latter.

Examples of function / procedure pairs that RAP generates: For the table "TBadmUser" in the canned "ExampleCRM" demo that comes with RAP, RAP generates these two routines for looking up records via the primary key:

UFTBadmUser#PK (user function)
SPTBadmUser#PK (stored procedure)

Why does RAP generate these routines, you might ask? Well the main reason is that RAP fully audits everything, and it gives you everything you need to retreive all data, both past and present. Unlike code you might write yourself, these routines let you choose (by passing either a date or a null) whether you are going to be retrieving current vs. archived data. All this will be covered later in the series.
Post #1003711
Posted Wednesday, October 13, 2010 9:05 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, April 24, 2012 5:33 AM
Points: 15, Visits: 120
A very interesting article. I have used variants of some of these suggestions and ideas in my own designs, plus a few of my own invention with extremely good results. The results have been applications that get done on budget, on time, are highly adaptable and have very simple maintenance requirements. That has proven to me that applications that do extremely complex things need not be complex or undecipherable. The article is a great swipe at the historical trend toward what I call "spaghetti and meatball" architecture.
Post #1003717
Posted Wednesday, October 13, 2010 9:21 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Tuesday, May 6, 2014 5:51 AM
Points: 6,266, Visits: 2,028
I used to build stuff this way loooooong time ago.

I would advice the author to look in to ORM products (that many are free) which contain MANY specifications and build everything posted here (and much more) from XML description files.

Just my $0.02

BTW my objections are only two:
- Please do NOT use Hungarian for database objects
- There is nothing wrong with not distinguishing between view and table in fact that is the point of using views.

Other than that I think people enrich their knowledge by observing different approaches to the same problem.



* Noel
Post #1003743
Posted Wednesday, October 13, 2010 9:32 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, May 8, 2013 9:31 AM
Points: 4, Visits: 61
Great series! I've been doing code gen for the past year and I love it. It is true RAD. As for the column naming, why does everyone care so much ? He said it was controversial. If you don't like it just change your templates if needed and go on with your day.
Post #1003753
Posted Wednesday, October 13, 2010 9:38 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 1:49 PM
Points: 897, Visits: 7,101
Unfortunately in the real world these important things constitute only a small fraction of developers’ time, because most developers spend most of their time:

reinventing data modeling (i.e. choosing from among too many modeling techniques)
reinventing database access on the database side
reinventing database access on the application side
reinventing business rule framework technology
diddling with endless details of UI component management
and reinventing UI design (i.e. choosing from among too many modeling techniques).


Really? Do you have any stats/research that backs up that assertion? I'm not an expert on what developers do but I have extensive experience as a DBA and managing groups of DBA's and I have to say that we spent very little time re-working our modeling techniques. We had standard tools and techniques. We used them. Once in a blue moon we re-examined our methods agains the latest and greatest tools and techniques and adjusted as necessary.

I'm not sure what 'reinventing database access' means. We had some utility programs that generated CRUD code for tables and/or views if we needed it, but that was a very small portion of the work done by the DBA staff.

We did have standards about how the DBMS was used. We had those standards because often we had little control over how the development groups wrote their applications. We opted to put the business logic near the data to help ensure consistency across the application portfolio. It worked.

So, from my perspective, you're solving a problem that may not really exist on the database side.





And then again, I might be wrong ...
David Webb
Post #1003757
Posted Wednesday, October 13, 2010 10:01 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
Really? Do you have any stats/research that backs up that assertion? I'm not an expert on what developers do but I have extensive experience as a DBA and managing groups of DBA's and I have to say that we spent very little time re-working our modeling techniques. We had standard tools and techniques. We used them. Once in a blue moon we re-examined our methods agains the latest and greatest tools and techniques and adjusted as necessary.

I'm not sure what 'reinventing database access' means. We had some utility programs that generated CRUD code for tables and/or views if we needed it, but that was a very small portion of the work done by the DBA staff.

We did have standards about how the DBMS was used. We had those standards because often we had little control over how the development groups wrote their applications. We opted to put the business logic near the data to help ensure consistency across the application portfolio. It worked.

So, from my perspective, you're solving a problem that may not really exist on the database side.



RAP does not really address the problems of DBAs, whose primary job is to maintain existing applications. RAP is about new application development, where someone has to decide exactly how to do all the things that the article lists. I assure you, from many many years of application development experience, that these are the things that consume most of new application developers' time.
Post #1003772
Posted Wednesday, October 13, 2010 10:36 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 1:49 PM
Points: 897, Visits: 7,101
RAP does not really address the problems of DBAs, whose primary job is to maintain existing applications. RAP is about new application development, where someone has to decide exactly how to do all the things that the article lists. I assure you, from many many years of application development experience, that these are the things that consume most of new application developers' time.


I guess that's where the disconnect comes from. My experience has mostly been in situations where the DBA team, or the data architecture team, did the data models for new applications. In most of the shops I've been in, DBAs didn't just keep things running, they were active participants in the application development process. They were involved from the very beginning, so we didn't see a lot of the thrashing around trying to figure out the tools or the modeling paradigm or the access pattern.

I think you're making a large assumption about the role of a DBA that may not be universally true. In organizations where the DBAs just keep the lights on and don't have any real understanding of the data over which they watch, you have bigger problems than the choice of application development tools.




And then again, I might be wrong ...
David Webb
Post #1003799
Posted Wednesday, October 13, 2010 3:50 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, January 9, 2013 3:27 PM
Points: 41, Visits: 51
It is not true to say that:
"Unfortunately in this day & age we still don't have relational databases that allow us to divide our various objects into different name spaces"
Sql Server has Schemas that can be used to place objects in! Tables and SP and Functions. Look at AdventureWorks for examples.
Oracle (swearing tis tis) has tablespaces and packages,but the effect is the same.
So it is preferred that prefixes aren't used and schemas are.

But this article doesn't take other aspects of architecture into account.
For instance:
- data modeling with Entity Framework or nHibernate
- error and exception handling logging and reporting
- message management (error and non-error)
And these are relevant for a small to medium size application

Then what if the application is successful and needs to scale up and be extended.
can it:
use services as a layer of Interfacing
be seperated into different teirs that work in a application farm with a load balancer
call other services without too much plumping
use other tools or techiniques such sockets communication, multiple level threading, multiple UI eg ASP.net, Silverlight

All these need to be considered when considering architecture for a even a small application, else you are planning NOT to be successful or locking the applicaiton out of being extendable or scalable

regards
GregJF
PS
Ford now make all kinds of cars. If Henry was still alive, we would be all driving black cars that look alike.
Or Ford would be bankrupted long ago
Honda succeeds because it is innovative and changes its achitecture often, Honing, honing,honing!

Post #1004014
Posted Wednesday, October 13, 2010 4:10 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, January 9, 2013 3:27 PM
Points: 41, Visits: 51
David
I think your approach is Ill convieved and out dated.
Today we write applications for the Enterprise or for the Sector(eg small retail).
All the "Aspects", "Prespectives" and "Viewports" of software architecture should be taken into account when design such applications.
The small retailer stills need auditing, although not as much, as the big enterprise retailer.

A better architectural approach to build upon a framework like .Net or Java and contruct the "Aspects", "Prespectives" and "Viewports" into a enterprise framework, that would suit a Enterprise or a Sector of the economy.

Think BIG! Design to Grow

regards

GregJF

Post #1004034
Posted Wednesday, October 13, 2010 4:25 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, November 6, 2013 2:24 PM
Points: 69, Visits: 182
GregFrazer (10/13/2010)
It is not true to say that:
"Unfortunately in this day & age we still don't have relational databases that allow us to divide our various objects into different name spaces"
Sql Server has Schemas that can be used to place objects in! Tables and SP and Functions. Look at AdventureWorks for examples.
Oracle (swearing tis tis) has tablespaces and packages,but the effect is the same.
So it is preferred that prefixes aren't used and schemas are.

One part of the purpose of the RAP prefixes, as illustrated in an earlier blog, is to allow you to differentiate multiple objects that really should have the name except for their basic natures (stored procs versus functions, for example). That is not something we would generally want to split across schemas (procs in one, functions in another). Another purpose of the prefixes is to simply allow you to categorize your objects without having to put them in different schemas.

But this article doesn't take other aspects of architecture into account.
For instance:
- data modeling with Entity Framework or nHibernate
- error and exception handling logging and reporting
- message management (error and non-error)
And these are relevant for a small to medium size application

RAP has its own built-in ORM that is far simpler than Entity Framework and nHibernate. In fact a specific objective of RAP is to allow you to build smaller apps without needing to read a 900-page instruction manual or build huge non-type-checked XML files. Exception logging and reporting are Enterprise Library add-ons that live in their own schemas and can be added to a RAP application.

Then what if the application is successful and needs to scale up and be extended.
can it:
use services as a layer of Interfacing
be seperated into different teirs that work in a application farm with a load balancer
call other services without too much plumping
use other tools or techiniques such sockets communication, multiple level threading, multiple UI eg ASP.net, Silverlight

Like all new products developed on a limited budget, RAP does not claim to be everything to everyone. I don't know the extent to which it can do all these things. Its purpose is to demonstrate what can be done automatically with a radically higher degree of standardization. If I were required to meet all these requirements right out of the box on the first try, then certainly I should give up and go home immediately.

Honda succeeds because it is innovative and changes its achitecture often, Honing, honing,honing!

Like me, Honda also did not start out with a full product line. Honda's first product was piston rings. Honda succeeded, step by step, by applying Deming's theory of quality management, which focuses entirely on eliminating useless and counterproductive variation in manufacture. That's why you can drive a Honda 200,000 miles without repairing it, and that in turn is why Honda and its Japanese siblings have totally upended the American automobile marketplace. American companies are constantly revising and honing their product lines too. Unfortunately they just don't get the "elmination of variation" thing (because their corporate managements are more into sales than engineering) and so they are closing plants and dealerships while the Japanese and Koreans are taking over.
Post #1004039
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse