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 4:28 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)
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.

OK .. let's see your implementation that can be generically applied to all reasonable-sized database-based apps and generate most of the code for you! I'm ready to download it & try it out.
Post #1004042
Posted Wednesday, October 13, 2010 6: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 just would not attempt to build an application or framework that is
"generically applied to all reasonable-sized database-based apps and generate most of the code for you"!!

I, and many others, would build and do build frameworks for industy sectors and enterprises.
These frameworks have "best pratice" (very debatable term) princples and patterns applied so that developers can utilise them as TOOLS and still write code that meets business needs.
These can then become the standards for those enterprises and maybe even the industry sectors.
Affording newcomers, and old hands, in that enterprise the standards, the tools and the framework to codify the business logic and rules inside a scalable, extensibly, interfaced and may even service oriented frameworked solution.
Try reading more on private clouds (eg,Programming WCF, Juval Lowy, 3rd edition).

Your idea is good just not the bit about "generically applied" AND "generate most of the code".
Turn it into a framework without the code generators.
Code generators can cause more trouble than they are worth. eg when they contain a bug, when they need to be changed or extended.

I am sorry, but I think your approach is incorrect. No amount of code I post is going to change that.

There is no silver bullet that does all thing for all programmers.

Embedding yourself in good architecture that is based on prinplces, patterns and practices
( read "Design Patterns: Elements of Reusable Object-Oriented Software",Gof4; "Patterns of Enterprise Application Architecture",Martin Fowler; and even "Architecting Microsoft .NET Solutions for the Enterprise",Dino Esperato
OR
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives - Nick Rozanski
)

regards

GregJF

Post #1004066
Posted Wednesday, October 13, 2010 10:30 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)
Your idea is good just not the bit about "generically applied" AND "generate most of the code". Turn it into a framework without the code generators.

Greg: I am thinking that one of us is missing the other's point here because we seem to be talking past each other. RAP does not presume to implement any particular functionality any more than a complier presumes to. RAP's entire purpose is to create applications (or frameworks or whatever) in a highly consistent manner rather than in the handcrafted manner that is pervasive today. To argue against the use of RAP (and everything like it) is analogous to arguing against the use of compilers and claiming that we'd be better off building and using application-specific libraries written in assembly language.

RAP is intentionally application-agnostic like a compiler is intentionally application-agnostic. It has to do with systemetizing the plumbing of applications, not defining their functionality.

Whether you are writing a "framework" or an active library component (like Microsoft's logging or authentication libraries that have their own databases), or whether you are writing apps that make use of those things, somebody somewhere has to actually be designing schemas, coding databases, coding data layers, building business rules and writing user interfaces. We have a choice here: we can code those things by hand (the "whatever the team comes up with" standard) or we can code them mostly automatically with a degree of precision that no human team could possibly attain. RAP's purpose is to do that.

So RAP has nothing to do with subscribing to (or not subscribing to) the use of frameworks and libraries and patterns and practices, except of course that it is based on the .NET framework. You are perfectly free to use RAP to build database-based libraries using whatever patterns and practices you choose.

Code generators can cause more trouble than they are worth. eg when they contain a bug, when they need to be changed or extended.

You've lost me here completely. Every compiler is a code generator. Would you advocate that we abandon compilers because of the possibility of a bug? Like a compiler, RAP generates hundreds or thousands of completely formed database and data layer routines and objects whose consistency and reliability would be quite beyond the capability of any human team to maintain. A RAP-generated database will contain precisely zero coding errors (and in the unlikely event of a bug, it would be easy to fix the bug and then truly be at zero coding errors). In constrast, I have never seen any significantly-sized human-maintained database that I would estimate to be anywhere near that level of error freedom.

Embedding yourself in good architecture that is based on prinplces, patterns and practices

There is nothing about RAP that precludes the use of principles, patterns and practices. The upper tiers of RAP in fact implement a strict MVC model, so RAP has a built in "pattern". Like MVC itself, RAP's implementation of it is application agnostic and so it is applicable to essentially all apps. RAP also contains its own highly reliable ORM, which is a library of sorts (a ton of code that people don't have to rewrite every time) that does a far better job of database interaction than I would expect any human team I've ever worked with to be able to generate.

So I guess I'm missing the point. There is nothing about the use of RAP (just as there is nothing about the use of compilers) that would preclude anything you're talking about. All the things you're talking about have to be implemented using some technology and RAP presumes to improve that technology (much as compilers are regarded as an improvement over assemblers).
Post #1004109
Posted Thursday, October 14, 2010 2:13 AM
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
So I and my customers invest in RAP(if not money, then time and effort) and rely on your assurances.

We do this for months or years.

Then we need to build a Silverlight front end that is quite complicated and needs to use data graphs to relate data and then send that the database. In Entity Framework 4, that is called a self tracked entity.
Does RAP do that?

Then we get successful and people want to get data from out App.
In WCF we would build an interface and expose it as a service.
Does RAP do that?

Then we get busy and we need to scale our app (code) on to an application farm and govern traffic by load balancers
With WCF and stateless code and BigIP(for eg) we can and have!
Does RAP do that?

Then we wish to performance monitor our applicaition
Take it international with Globalization.
Does RAP do these?

OR do we have ot after many months refactor our code out of rap and build a non-RAP framework to get these things done.

OR do we have to wait until you put these things into RAP

BTW code generators that make other C#/VB.net are NOT the same as compliers. Compliers have syntax checking, type checking etc.
These C#/VB.net code generators make LOGICAL errors that are near impossible to debug.
And any major enhancements, like those above need MAJOR updates to the code Generator.

You certainly haven't conivnce me.
Also in the example you got us to load some SQL scripts.
Which created 222 Stored Procedures and 132 Functions
So your claim of no database programming is not evident.

Also what if we need to add a table or to add a column, does that need SP changes?
Do we need to go back to RAP to get another release?

This is asking more questins than it answers

Regards

GregJF

Regrads
Post #1004168
Posted Thursday, October 14, 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
I've been using https://sourceforge.net/projects/mygeneration/ for a while now. It's not identical to RAP but it's a code generator. The way I have designed my templates solves about 90% of the things you listed. My templates create a MVVM WPF/Silverlight application.
It takes a database schema that is well defined.
It creates:
* the stored procedures that application will need to access the data
* the the Model classes for each database entity
* * The model classes have built in validations that are derived from the schema such as null checks, length checks, or even constraints added using CHECK at the database level. This allows the application to tell you when something is wrong even before you have saved it. (What are the chances you wouldn't mess one of those up if you did that by hand ?)
* the DAO interfaces that the application will use to ask for data
* * a SQL DAO implementation that will be used by the WCF service
* * a WCF DAO implementation that the application can use to connect to my WCF service
* the WCF Service
* the management layer that tracks all the changes to my object and keeps everything in sync
* the various view models for managing each entity
* the XAML for the views (very generic)
* the thread manager to make sure all blocking calls run async so the application is always responsive.

I can generate about 90% of the code for my applications with a push of a button. Everything is consistent from one application to another. If you add a column to a table, or change a definition some where just regenerate everything and you are done. No having to spend hours going through thousands of lines of code updating everything.
I can spend core of my time worrying about the user interface and how the user interacts with my application instead of all the implementation details.
If a bug is found you just fix it in the template and regenerate again and you are done.

Overall it's a beautiful concept.
Post #1004501
Posted Thursday, October 14, 2010 12:00 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/14/2010)
David
You certainly haven't conivnce me.

Greg: Truly and honestly, I am glad that there are some projects where relatively advanced needs like yours are being met, and where the programmers are so good and so consistent that they don't need code generators to help them out. I would say that RAP has little to offer you.

Not all of us are so fortunate however. I operate in environments where the databases don't have explicitly declared primary keys, foreign keys, indexes, and so forth, and the whole thing more resembles a collection of "flat files" than a database. I would guess that at least half the application programmers out there couldn't tell you what an ORM is, let alone enumerate the features of Entity Framework. The vast majority of programmers working today probably could not tell you what "first normal form" is, nor would they care enough to tolerate an explanation. Almost all the schema desigs I've seen feature grossly inconsistent uses of keys and status fields and are consequently a nightmare to maintain. The code (both in the database and the app) is generally a pile of undocumented spaghetti that requires hours for me to discern the intended funcionality. Outside of the few best-managed companies, his is the industry norm I'm afraid.

RAP is intended to raise the standards of the enormous bottom end of the industry by doing automatically what apparently so many programmers cannot or will not do for themselves. American industry is losing vast sums of money due to the poor design, inefficency and high error rate of the software that it pays people to develop. In my opinion, easily half the running apps today are dismal design failures whose shortcomings are not obvious only because most American management is basically uninterested in either application design or quality control ... and because there are no obvious alternatives. And I'm not even counting here the apps that were such total failures that they never even entered production.

It seems to me that all of American business is potentially poised for a smackdown comparable to what happened to our auto industry. If most of our underlying apps and schemas resemble most of the stuff I've seen, our companies will be fundamentally unable to respond to any challenge from anyone using any serious software quality control mechanisms. Could there come a day when essentially all American business is noncompetitive due to poor software app quality? Fifty years ago if you had suggested that the American automobile market would someday be dominated by non-Americans, and that they would dominate predominantly based upon their quality control (which derives from consistency), you would have been laughed at.

So please bear with me. Most app designers couldn't design a comprehensive auditing system on a dare; RAP gives it to them for free. Most apps don't do concurrency management; RAP provides it automatically. Most apps don't dare to ever actually delete records, thereby defeating referential integrity and smothering live data in obsolete data; RAP solves all these problems automatically. The list goes on and on.

So no, RAP is not trying to compete with top-end designs requiring the full features of Entity Framework. RAP is at the other end, trying to clean up the enormous mess.
Post #1004690
Posted Thursday, October 14, 2010 3:15 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 11:32 AM
Points: 152, Visits: 961
Thanks David, for such a fine article. After decades of quality training and Six Sigma classes, I believe your predictions about the demise of the unproductive American programmer may happen. It is ego that refuses to give up creativity in deference to proven designs. Much of the repetitive code where I work, is generated by CodeSmith and by in-house tools which allow us to deliver standardized apps very quickly.

Reducing variation should be the primary goal, if you want to deliver bug-free code quickly.
Post #1004815
Posted Thursday, October 14, 2010 4:18 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 have been coding to databases for nearly 30 years. (I don't come from America(nth, sth or in between))

And I agree with you about most "designers". They need a re-education of what programming is!!

I think nHiberate and Entity Framework are better solutions(tools) than using stored procedures to maintain a database. Although I have reservations about their ability to Create a database or tables therein.
But you need to know the RDBMS to make good design decisions (eg refain from Views in SQL SERVER, embrace them in Oracle; same as with CURSORS. not for SQL SERVER but great in ORACLE) and you need to know the business domain to be able to optimise those databases for best effect.(eg look how a CLUSTERED indexes affect Inserts and therefore which keys to use as CLUSTERED, most of the time never the auto-generated number key.)

But if programmers use these data modelling tools they will not return to SPs. Except when the modelling tools can't do what a SP/Function can, or for elaborate reporting.

So I suppose that my approach to build Enterprise frameworks and educate/mentor young programmers to take a life approach to their own learnings. I just don't like spoon feeding people, even if it is good for them.

As far as management... Don't get me started else this will actually get much longer and dirtier.

As I said before, in general your Idea is good but it shouldn't impose a non-industry naming convention, have the ability to swap out tiers(refactor) for a better solution, be scalable(application farming), be expandable(add more features, coding and datastore), be able to be comunicated with(services) and most of all, be totally maintainable(no black boxes).

I would rather start programmers off by teaching these things than to hide these things from them.

Best of Luck

GregJF
Post #1004835
Posted Friday, October 15, 2010 8:33 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, April 24, 2012 5:33 AM
Points: 15, Visits: 120
David Ziffer (10/14/2010)

... American industry is losing vast sums of money due to the poor design, inefficiency and high error rate of the software that it pays people to develop. In my opinion, easily half the running apps today are dismal design failures whose shortcomings are not obvious only because most American management is basically uninterested in either application design or quality control ... and because there are no obvious alternatives. ...

and

It seems to me that all of American business is potentially poised for a smackdown comparable to what happened to our auto industry.


I believe the "smackdown" has started but the alternative is faring no better. When the small engineering company I worked for was acquired by a large corporation, my development team was disbanded by corporate decree that software development had to be outsourced. Efficiency, quality and our high performance user front ends disappeared as Indian code factories cranked out so-called industry standard apps. The "corporate" goal to reduce admin user time per technical report succeeded (10 mins. to 7 mins.) while ignoring professional user time (30 mins. to 120 mins.). The defense was that the outsourced app "met industry standards" and complied with corporate policy for development. Of course the people who decreed this policy will never have to use the app or take responsibility for the reduced productivity of the professional staff.

The net result, in my opinion, is to produce low quality apps with the illusion of lower costs. Your approach can change that, but it is not complete. Good development tools can still produce junk, faster and cheaper, whether they are used here or in India. That being said, at least good development tools allow the designers to focus on what makes a good application, and it isn't the hand-wired vacuum tube breadboards they are designing now.

I'll certainly give RAP a fair try. It looks promising provided I keep in mind that meeting the criteria for a productive application (from both a user and maintenance standpoint) is still my responsibility.

Post #1005244
Posted Saturday, October 16, 2010 6:56 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
ismell (10/14/2010)
I've been using https://sourceforge.net/projects/mygeneration/ for a while now. It's not identical to RAP but it's a code generator

Thank you for this reference. I was unaware of this and will check it out. -the author
Post #1005717
« Prev Topic | Next Topic »

Add to briefcase «««12345»»»

Permissions Expand / Collapse