LightSwitch—the Discussion Continues

As to stored procedures: I saw a post today that said the target developer for LightSwitch (LS) would not be technically competent to use stored procedures. Ah, no. No one (in their right mind) is saying that the LS developer would need to learn to write stored procedures—just leverage them. That’s the point. Stored procedures (and Views to a lesser extent) decouple the application and the developer from the complexity of queries and updates—operations tuned to protect and properly share the data. They are created and managed by the DBA—not the inept developer (Visual Basic, C# or LS). We often recommend stored procedures to clients that have UI-aware or report developers that need not know what’s going on behind the scenes.

Another (new) point: Ah, does LS do any better with evolving schemas so typical during application development? That is, when a developer starts working a problem, he or she lays down a table (in whatever tool they are using) given the understanding of the problem at hand. They go on to build a front-end to query the data and perhaps post changes. So far so good. However, as soon as the application is shown to the customer (the ultimate consumer), or the developer starts to use the application, it’s discovered that the table needs to change. So, the developer goes back to the table-authoring tool and changes the schema. Perhaps she adds a few columns or change a datatype or two. (Can I assume that LS knows how to modify a populated database?) Now it’s time to make the UI match the schema. In Visual Studio and the TableAdapter we have to basically start the UI over—do all of the drag-drop again. Even if the visual UI does not change, the generated code does not match the datatypes. Now what? Does LS automatically morph the UI and generated code to match the current table schema? If so, how is this done and can it be applied to future versions of Visual Studio’s code generators?

Another (new) point: One of the issues raised* about 20 years ago when we first started seeing RAD application development is how business rules are handled by the UI. IMHO these need to be handled on the client (at least to some extent)—especially the basic ones like min, max, default, acceptable range, mask and the like. Yes, business rules ultimately need to enforced in the database (thus stored procedures, rules and constraints) but the UI needs to help the application consumer (the source of the information) enter (or choose) the correct data values. Up to this point, Visual Studio and its code generators do little to support the developer manage these values which (again IMHO) should be stored in the database schema and applied to the application UI code as its being generated. As a result we have to imbed a great deal of brittle code into the application or enable our own dynamic BR management schemes. A number of us lobbied the SQL Server team to incorporate Extended Properties into the SQL Server infrastructure and this was done precisely to support this approach. MS’s Visual Studio team never took the ball and ran with it. I expect they were too worried about adding functionality that would benefit SQL Server over Oracle. Question: does LS deal with business rules any better than Visual Studio?

* Hitchhiker’s Guide to VBSQL (first edition)