|
|
Design Goals
The application framework SQL-Hero is built on was not constructed in a vacuum. It borrows many concepts from successful projects (and other application frameworks) and SQL-Hero has grown out of a desire to complement the framework (and vice versa).
Must work in an n-tier application architecture. What this means is one should be able to construct a service layer and pass objects between layers freely.
Ideally, it would "play well" with remoting technologies such as WCF, using standard data contracts.
Changes in application topology should involve a limited amount of effort.
Must support the construction of complex screens, while minimizing the effort. The best way to express this is not by strictly looking at "lines of code," but at the general level of readability and therefore maintainability.
At the same time, a screen can demand many things such as knowing the original values for
underlying data, being able to "undo" changes, present and manipulate data that has no resemblance to either physical or traditional logical data models, and so on.
Often times there are vigorous debates about which tier data manipulation should be limited to: one could do a lot in stored procedures or nothing in stored procedures, for example.
Reality says one needs to balance "purist" desires (which sometimes relate to maintainability) with performance considerations. (As a side note, consider the example of an insistence of not doing much to anything in stored procedures.
For a search screen that does anything non-trivial such as outer joins, EXISTS, NOT EXISTS checks, multiple steps involving temporary tables, etc. - this could be exceedingly difficult to NOT do with some piece of code that doesn't look a bit daunting - .NET or SQL - since in the end, you'll need some complex SQL to do what you need.)
Consider the performance issue of joining data from numerous tables for the purposes of presenting in a grid. This tends to dictate that one use SQL for what SQL does best: set-based operations that are efficiently processed by a cost-based query parser.
Assuming that's the case, now you could have a screen that uses a grid which relates to no single business entity but a custom entity instead which is sourced from a stored procedure.
So now the question becomes, "how easy is it to go from a raw query - i.e. stored procedure - to a business object?" - a design goal for CodeX is to make this easy
and offer up options.
Must adapt well to underlying data model changes. This is often realized through mechanisms such as strong-typing and liberal use of code generation that begins at the physical layer and works its way up.
Must be able to "point" the application at different "regions", easily. A "region" refers to the fact that one should typically have different databases to support development, QA / user testing and production. "Pointing" refers to the ability to easily debug an application which might be running in the Visual Studio IDE with the development code base, pointed at QA or production data.
Why is this important? Sometimes application issues can only be reproduced with data in different regions. This ability should extend beyond just pointing at different databases. If an application has a service tier, one should be able to point at different application servers, or your local machine to support debugging.
Must work well with technologies such as LINQ to Objects. LINQ in this case can greatly simplify code that might otherwise involve complex looping mixed with conditionals. Even technologies such as Enterprise Framework will find ways to work with SQL-Hero.
Must be able to generate the maximum amount of functionality using meta-data and declarative techniques. One might assert that we already have this with Domain Specific Languages (DSL), and although true in principle - in practice, we need tools that are easily understood by all, are relatively inexpensive and are flexible enough still meet the other requirements outlined here. Not a lot of tools do all this in a one-stop manner today.
|