Verbatim Identifiers in C#

Not that many people realize that in C#, one can use language keyword names like "void" and "bool" for their identifiers.

The trick is, you need to prefix the name i.e.:

 void @void() {}

declares method named "void".

Of course you would rarely use this feature, if ever but many people start arguing "Why Microsoft did this to begin with?"

I am personally 100% on-board with MS on this one, - not only this is a good practice to be consistent in language design (less limitations) by allowing programmer to use any name

 but this is a must-have feature i.e. you may code an assembly in Delphi Prism( as an example) and call a method "void" -

 then you'd need to consume it in C#. "void" is not a keyword in that language.

I personally think that purposely naming you stuff with "dangerous" names is a bad thing, but having verbatim name capability makes us feel more liberated :)

Aum Syntax Samples: constrained domains

Working on contrained types(domains) idea, proposed syntax:
--------------------------------------------


use RTL;

scope Test begin

//Domain with constrain

public domain HumanAge(int)
{
value >= 0 and value <= 150; }

public static class Program1 begin

public method Main

{

Console.WriteLine("Hello Delphi days!");

Console.ReadLine();

Console.WriteLine("About to crash");

var age: HumanAge;

age = 500; // CRASH!!!!!! Domain is constrained and did not pass validation

}

end;

end;

ORM Condemnation (....Continued)

Did I tell you that I am not a fan of OR Mapping solutions at all?

Why?

Because of concept and code bloat and very little benefit (if any). I am teaching developers this way:

Majority of business applications are comprised of 3 major parts:

a. Master Data - such as dictionaries and support tables

b. Normal Processing/OLTP  - used every day, this is what app is used for, usually real-world data is keyed on [a] and stored depending on some sort of a date/time key

c. Reports - query transactional-accumulated(or live) data (entered in [b]) , join it with master data for descriptions and output to user

The fact of life is that "Master Data" tables (hundreds of them in big systems) are very dummy in the most cases, and any credible architect

 would build interfaces/CRUD logic in a template-based way. For those templates(base classes probably) SQLs are usually very simple, the row count is mostly <1000 per table (not always),

 and really there is NO BUSINESS logic needed to be applied but map SQL columns to on-screen controls (be it Forms, Web or anything else). Making developer

 maintain a bloat of 100s of classes just to map A to A does not make much sense. What does make sense - build your general ancestor class smart enough

 to supply tons of metadata from your back-end automatically (such as max-length, required(not null), format etc...). I don't really need to map DB to object for that.

Now about [b] item - OLTP screens or entry processes(be it GUI or ETL or...who knows). Those definitely need to go through good interface in terms of classes, but again, if you have ever built 

 "big" software that contains 100s of data-entry screens - the pattern becomes trending - you are NOT dealing with simple SQLs - now when user hits  "Save"

 you probably touch 3-10 tables etc. I personally never user ORM for that but write classes by hand with plenty of XML comments and human methods

 that are centered around business , not around schema. Database schema is designed for normal-forms compliance (most of the times), not class/interface

usability by developers. So, in a financial system, I would have "Portfolio" class and "Save" method, and maybe even "IStorage" provider that implements

 direct SQL backing store so portfolios could save ,or maybe middle-tier store. So SQL is not the sole solution now.

 The hand-written code makes sense though, and there is no bloat. Using LINQ to SQL would not have helped really as "Save" method for portfolios

 touches 10s of tables due to business rules. And I don't really want to have database code in C#, maybe database orchestration code I do, I'd rather use stored proc, or maybe some other middle tier process as an abstraction layer. So now I need to use ORM there, again, I need to write good well-though queries that don't put unneeded locks etc..

So what benefit does LINQ to SQL/Hibernate/EF or any other tool would give in my case?  None. 

Check out this link regarding Microsoft ORM technologies trending:

http://www.infoq.com/news/2008/11/DLINQ-Future

IE9 - end of Flash(Silverlight)?

Interesting page dedicated to IE9 - Microsoft has decided to support SVG, HTML5 including hardware-backed rendering and better CSS-3 standards.

What is missing as of today is Canvas object model though rumor has it - Microsoft will support it,

consequently question arises - if all modern browsers support:

1. Consistent DOM event model

2. Fast JavaScript (they have made it already 7+ times faster in IE9 vs IE8)

3. Direct drawing capability (Canvas) with styling and prof anti-aliasing

4. Vector graphic support built-in: SVG/Canvas

5. HTML -level  audio and video tags (no player plugins)

, then does Flash (and especially Silverlight) have any future in 5 years from now?

This makes perfect sense - browser becomes "Flash", and for those who claim that JavaScript is "not a language" suitable for development

I recommend to re-evaluate their perceptions - Java Script is VERY powerful if you know how to organize code in 

 namespaces and use encapsulation and other OO patterns that ARE available in JS.

See this:

http://ie.microsoft.com/testdrive/

Do you know CSS?

Before you answer,,,just check the link below first....

http://www.romancortes.com/blog/tag/css/

So do you know CSS?

Well it's all a hack....I know.

But still cool!

ORM Idiotizm

For the over 10 past years I have been a strong critic of ORM concept. I feel that majority of people just don't understand the root

of the problem with ORM, don't understand what ORM is for, and even should it be there in the first place. I truly think that it should not,

the whole concept of ORM is wrong and here is why. I'll be talking in very practical terms. 

What is ORM? ORM allows us to map relational entities (read "tables" with keys and references) into objects in your code. Sounds very cool.

Let me ask you a "stupid" question -  why do you need to have those objects in your code to begin with? Huh? No, wait, don't close this page, keep on

 reading....why? Ah...because you need to show the grid of customers then change selected customer and save it back to db.

 Ok, let's start from display grid(or any kind of list, such as a treeview), so grid is object-oriented piece of software that "draws" lines on screen (or HTML)

 that mimics a table, also it draws little string values in those "cells", so grid needs to get some data to draw. OK, but don't we have data in database? We do.

Can we read this data? We can. Can we read different column types? We can. Can we know what columns are in there(in database/table). Yes, we can. Can we build grid directly from database. We can.  Can we do this automatically relying on database meta-data (data about columns, sizes, requirement etc...) WE CAN.

So, why do we need stupid POJO or POCO objects in between to draw grids? We do not. We need a "smart adapter", - a class that is absolutely universal -

 it takes "data descriptor" (think of DataTable,DataSet,DataRow in .NET) and build grid columns including their default width, maybe even color to indicate importance, etc..

This class ("adapter") may also take custom style-rule set that will hide certain columns or make them smaller - but this is just for DISPLAY ONLY purpose.

Back in 1995 I have used client-server database and I needed to build an application with 200 data-entry screens. What I did, I created a grid-derivative that was "so smart" -

 in 90% of cases I just wrote a select SQL - formed a dataSource and then grid showed it to me in design time (I used Delphi 1) where I dragged and colored columns to make them look pretty. Thats it!  No Line of code was written in business layer, no line of code in the grid form, just NONE. No strings to configure, and when you add columns to database - they may or may not automatically appear in the grid for corresponding table, depending on 'AutoRebuildColumns' boolean property. It also worked much faster than Hibernate (that did not exist back then) because it did not create any redundant copies of data in memory(no POJO/POCO).

Same approach for displaying detail forms: textboxes, checkmarks, radios etc...  All you need is this: allow developer to place controls on form to satisfy client's particular layout requirements,

 wire-up every data-entry control DIRECTLY to database column by name (i'll explain how) and write NO BOILER PLATE CODE. If column "Sex" is required in table "Customer" then radio-button should automatically be named "SEX" and be required upon 'Save". You don't need to write any validation code, any "Validators" - this is all extra work and really not needed - everything is already explicitly defined in your database schema. 

How to connect , say textbox directly to TABLE.COLUMN in database? Easy - you need to write some "framework" code that make your textbox "smart" by associating this data-entry field with particular column by STRING NAME, make a property "FieldName", and then everything should be read from metadata and applied to "object-oriented" properties of a text box, such as: Readonly, MaxSize  etc...   Some properties do not exist in DB, i.e. "text color" but that can be specified by developer in concrete form.

You feel what I am getting at here? Yes, AUTOMATIC DATABASE REFLECTION, with 100% CUSTOMIZATION ability by developer in every screen, but this is much more rare that just displaying/saving data back and forth in "default way" - without special customization.

Ok, now another part - working with "BUSINESS" objects. The truth is that in may cases you just don't need a business object because you are interfacing with

 table that has limited functionality, column and row count (think US_STATES table). For complex objects such as "Patient Medical Record" Hibernate and the like dont do you much good anyway, reason being - you need to have 100% control over SQL code/stored procedures being sent to database, and yes HQL is a language of Hibernate, but wait, why do I need it, I already know PL/SQL or t-SQL and know it well, and it has operators that Hibernate does not even dream about (think of compilation hints, things like grouping sets, CONNECT BY etc...).  So when I save 'Patient Medical Record" I certainly use CRUD-like helpers but definitely not a monster like Hibernate or MS Entity framework.

One last thought -  when you use LINQ that you all love so much, don't forget that LINQ knows nothing about your collections in terms of indexes....binary searches...

 consequently it is all very slow linear search ..... some food for thought.... LINQ to SQL? I'd rather use SQL to C# (its a joke).

Let's use excavator to dig swimming pool and spoon to eat cake but not vice-versa.

Read this link below, it will open you eyes!

http://incubator.apache.org/empire-db/empiredb/hibernate.htm