(side note) >> sqlStmt += " CITY = '" + txtCity.Text + "' "; // London ; )
I really hope you are protecting your database more than this in reality and this was just for the simplicity of the example. A user could do
SQL injection if they wanted very easily. While it's more popular to do SQL injection in web apps, it can happen in Win apps as well.
The LINQ stuff is really great, the comments about performing joins across multiple sources is intriguing. I could select email from outlook, have it join where the from address matches values in ActiveDirectory for a specific group... so you could pull out
all emails from administrators, for a simple example.
The danger I see, however, is that it could be very easily abused and not completely understood so that some very slow queries would be written.
In the above example, I'd imagine that since the two pieces of results are coming from different sources (one from AD and one from your email source) that each would be returned and joined in memory. That means that I may have 1000 emails and only one of them
is from an admin but all 1000 emails are returned before the joining can occur. The compiler wouldn't know that the list of admins is small enough to execute it first and pass it in as a param to the email engine so that it would only return that one email.
When first watching, I had the thought "ok, now so many things are so much simpler that it allows amateurs to do what normally required a professional" maybe now the differentiator will be that I will understand enough of how it is all working that my code
will designed to run significantly faster.
It's all great stuff. I love that through the type inferencing and dynamically generated classes, it has the ease of non-typed languages (Ruby) without losing the performance and benefits of strong typing.
I am glad MS is having these WF screencasts. I agree with the other commenters that the demo doesn't show a good real-world example though.
Another problem is the lack of proper separation of the layers: it's tying business-logic directly to the UI, making it brittle and the rules are not reusable (in other forms in the same app or in different apps). I should have an Order object, set up the Rules
for that object and instead of manipulating the .text property of the winform controls directly, I should be altering the instance of the Order object that the Order Entry form is presenting (through databinding). Then, due to this separation, the same validation
rules and behaviors could be applied to other presentation layers (ASP.NET, CompactFramework) without duplicating all the rules (our apps have a TON of rules that can vary by customer).
If this can be done, then that is the type of screencasts we should be seeing, a best-practices demo, without hardcoded prices and without tying the business logic directly to the UI, but to the underlying objects to which the UI is bound. Otherwise,
I'm sure many programmers will end up incorrectly thinking that the way this webcast presents it is the best practice or if they recognize that it isn't, they won't have an example of what a best-practice example does look like.
There should be a set of validation rules you set up for the Model, and the UI should have a way to hook into the results of the validation tests. Ideally the WinForms/ASP.NET/CF controls would all know how to get the message from the Validation engine that
the text entered is incorrect with the ability to have a user-defined style applied to the control (red borders, red background, red text or a red dot next to the edit/check box or set up an event handler for ValidationFailed event) with a float-over hint
that ties back to the error message in the user's appropriate language. Then you could databind a label to the validation engine results so it could show all the failures on the form in User-readable text format as defined in the Validation Engine of the Business
Rules layer, but definitely not the Presentation layer.
For an example of a framework that does this, go here
http://www.oakleafsd.com/ and check out MereMortals. While I've not used it, the online screen casts show how the exact same validation rules are used for both the Windows front end as well as the asp.net front end -- coded once. The problem with
their approach is that they have to subclass all of the winforms/webforms controls to be able to support the extra features. It would be nice to see something like MM's features native to .NET and could be used in different ways by various presentation layers.
The validation error messages should be easily localizable.
The direction we should be seeing from MS is toward finding the best ways to properly separate the layers so that even more code is reusable. The presentation layer should have as little code as humanly possible. Then when we want to switch to Avalon or some
other future front end technology, there is very little that needs to be done, if we want to create a simplified version to run on CF, it should be simple.
Let's say I add a new restriction to the Order object, I should be able to add it only to the validation engine then WebForms, Winforms, Avalon and CF forms should all automatically present the validation error to the user without any coding
or even recompiling of the presentation layer on any form that attempts to post bad data.
For the best developer experience, the business objects could be a part of an object persistence framework which would allow me to pass an Order object to the form, the form would have a holder for that Order object and then other controls would use that holder
as their datasource, with the ability to reference the object properties as a part of what they are bound to. If you look at Delphi's ECO (Enterprise Core Objects) it allows for this, with substantially more databinding ability than .NET. It allows you to
write OCL (Object Contraint Language -- which MS was part of developing the standards for, along with Rational) which can do if/then and other control structures, type conversions, user-defined calls, etc to define what is shown in a control. A grid on the
order form would then have the grid datasource set to "thisOrder.OrderDetails" and with each column able to reference the different properties/fields of the OrderDetail objects in the OrderDetails collection found on the Order object.
Now that Borland sold Delphi (and it's other IDEs), it'd be great if MS would buy or license the ECO (which is written in .NET) technology from DevCo (the buyer) and make it core to the .NET developer experience.