What I wrote is literally true, but maybe
there is some humor in there somewhere.
For WCF, LINQ, and WPF, we looked at the
documentation, and it was clear that just
working through the tough parts of the documentation
alone would be much more work than just writing
our code directly. Moreover, any bugs,
security problems, need for updates, etc. of
WCF, LINQ, and WPF we just neatly avoided.
And we saved maybe a lot of address space.
That is, it looked to us like, for us, YMMV,
WCF, LINQ, and WPF are a candle not worth
the match. I can believe that in some
situations those three could have some value;
for us, I don't see the value.
I mean, WCF boils down to TCP/IP raw sockets,
right? Well, the API to raw sockets is
about the easiest I/O one could hope for,
nearly as easy as the ancient Basic statement
PRINT or the same in C, etc. I tried for
several days to make sense out of WCF,
came up with zip, zilch, zero, nichts,
nil, nada, and gave up,
but I learned raw sockets in about three
hours one afternoon decades ago. To heck
with WCF.
For LINQ, that boils down to just SQL, right?
Well, SQL was supposed to be really easy to
use, is profusely documented, and has been,
for decades, has long been an ANSI
standard, has been tested in various ways,
and with astounding severity, around the world,
for decades, right? So, writing some SQL
is not so tough. Getting a connection
string to SQL Server? Yup, that took two
weeks of mud wrestling, but the SQL statements
were easy enough to write. SQL's fine.
Very glad to have it. SQL Server connection
string mud wrestling? Did I mention some
bad documentation? The full power of the
Microsoft Corporation still is unable
to document how to write SQL Server
connection strings. The only way I
learned was via Google searches wherever,
and then I did some organized trials
of essentially all possible combinations
of everything involved until it appeared
to work. I still don't know just why
what worked did and what didn't work
didn't. Cave men with burnt sticks
wrote better documentation on cave
walls.
For our SQL Server database schema,
that is, the specifications of
the tables, the columns, etc.,
we have a little file, just awash in
comments, nicely clear and easy to read,
that we run through
the wonderful SQLCMD.EXE -- "Look,
Ma, no GUIs!". And no clicking!
Instead, just type the name of a little
script, and presto, boom, have
a new database created just as
want, nearly no chance of anything
going wrong. It's better than most sex!
For the SQL Server Management Studio, can use
it read only a little and otherwise just
can't make sense out of most of the screens,
windows, sub-windows, check boxes, terminology,
concepts, etc.
So, for SQL Server administration,
just back to the simplest
little SQL statements, mostly industry standard.
The SQL Server documentation of users, logins,
etc. wins the prize for the worst technical
writing I ever saw. But, do some Google
searches, go to some Web sites, and see
that just some fairly simple SQL statements
are enough for such administration work.
So, get a collection of little SQL files,
run them through the wonderful, fantastic,
we're lovin' it, SQLCMD.EXE, document
the little files and their usage, and, fine --
f'get about Management Studio.
Basically, right, really prefer
command lines to GUIs! GUIs? Far
too difficult to understand,
get to work, script,
document, etc. We'll let the
cognitive psychologists at Xerox
PARC, Steve Jobs, etc. play with
direct manipulation GUIs, and we'll
stay with command lines, scripts
driving command lines, and a text
editor writing the scripts. Sorry
'bout that. To each their own.
If you like GUIs, then go for it.
YMMV.
WPF? Maybe that boils down to Windows
Forms for a native Windows application,
but our only GUI is HTML and CSS
with the little JavaScript ASP.NET writes
for us. If WPF boils down to HTML elements,
then, sure, we'll just use, directly, HTML elements
and/or the ASP.NET class wrappers for
those elements to make the HTML
programmable, that is, be able to
generate HTML elements via software
that executes for each user
uniquely after they connect.
So, we just saved having to read some
hundreds of Web pages at MSDN, buy
a cubic foot or so of books, do 500
Google searches about details, submit
100 questions to Stack Overflow and
the MSFT fora, etc.
Our code so far is about 30 KLOC
(that is, actual VB statements)
with maybe 60 KLOC of blank lines
and 100 KLOC of comments.
It seems we share a similar philosophy. My SQL code is actually generated by the client. The server also generates its own SQL code, and does its own DB admin (create and drop tables, insert seed data and so on).
I think I need to look into TCP/IP sockets though. I have a very simple WCF service that accepts a byte array, and returns a byte array. No more, no less. The back-end deserializes the bytes and does what it needs to. WCF configuration is a Night! Mare! I think someone got completely spannered on the dependency injection koolaid. My service is a single method, and I spend more time babysitting XML in Web.Config than I do writing the service...
And yeah, with white space and comments my code base is around 120 LKOC. Just under 140 if I include the Windows Phone client.
Long ago I concluded that in tools,
ease of use was tools that were
reliable, did fairly simple things,
and were easy to understand how to
use and not tools that tried to do
a lot, do favors, anticipate what I wanted,
and do more for (to!) me!
So, in a kitchen, I don't want a hot dog
cooker and, instead, can, depending on
what I want, just use a pot and with
water and boil the hotdogs, use a skillet
with some oil and fry the hot dogs, or
go on the back porch, build a charcoal
fire, and broil the hotdogs. Besides, for
a hotdog cooker, how to clean the darned
thing! And have to get it out of storage,
set it up, etc. No thanks.
For cutting onions, use my best three tools
in a kitchen, a good French chef's knife,
a cutting board, and my hands. Works great
also for potatoes, carrots, cabbage, garlic,
and much more.
In a shop, have saws, hammers, files, wrenches,
screwdrivers, a drill plate, drill bits,
a nice, variables speed, reversible 3/8"
electric (not battery powered -- don't want
to mud wrestle with batteries that run down,
need charging, go dead, wear out, get weak, need to
be replaced, etc.) drill. Also
socket wrenches, etc. But lots of automatic
tools, e.g., a screwdriver that has a spiral
shaft that push on to turn a screw, don't want.
To sharpen a kitchen knife? Sure, just use
whatever grit size sand paper, usually
silicon carbide, want, put the paper flat
on the cutting board, and sharpen away.
Simple tools, that do simple things, and are
reliable and easy to understand. Then, build
more on those.
So, just use TCP/IP raw sockets and build more
on those.
For a session state server, use TCP/IP raw sockets,
de/serialization, and two collection classes.
Piece of cake, no use of CONFIG whatever, no
use of XML, only a few pages of documentation,
lots of good, old code samples, rock solidly
reliable ("TCP/IP sockets are the workhorse of
all of the Web and Internet")
etc. By far the
easy way.
For WCF, LINQ, and WPF, we looked at the documentation, and it was clear that just working through the tough parts of the documentation alone would be much more work than just writing our code directly. Moreover, any bugs, security problems, need for updates, etc. of WCF, LINQ, and WPF we just neatly avoided.
And we saved maybe a lot of address space.
That is, it looked to us like, for us, YMMV, WCF, LINQ, and WPF are a candle not worth the match. I can believe that in some situations those three could have some value; for us, I don't see the value.
I mean, WCF boils down to TCP/IP raw sockets, right? Well, the API to raw sockets is about the easiest I/O one could hope for, nearly as easy as the ancient Basic statement PRINT or the same in C, etc. I tried for several days to make sense out of WCF, came up with zip, zilch, zero, nichts, nil, nada, and gave up, but I learned raw sockets in about three hours one afternoon decades ago. To heck with WCF.
For LINQ, that boils down to just SQL, right? Well, SQL was supposed to be really easy to use, is profusely documented, and has been, for decades, has long been an ANSI standard, has been tested in various ways, and with astounding severity, around the world, for decades, right? So, writing some SQL is not so tough. Getting a connection string to SQL Server? Yup, that took two weeks of mud wrestling, but the SQL statements were easy enough to write. SQL's fine. Very glad to have it. SQL Server connection string mud wrestling? Did I mention some bad documentation? The full power of the Microsoft Corporation still is unable to document how to write SQL Server connection strings. The only way I learned was via Google searches wherever, and then I did some organized trials of essentially all possible combinations of everything involved until it appeared to work. I still don't know just why what worked did and what didn't work didn't. Cave men with burnt sticks wrote better documentation on cave walls.
For our SQL Server database schema, that is, the specifications of the tables, the columns, etc., we have a little file, just awash in comments, nicely clear and easy to read, that we run through the wonderful SQLCMD.EXE -- "Look, Ma, no GUIs!". And no clicking! Instead, just type the name of a little script, and presto, boom, have a new database created just as want, nearly no chance of anything going wrong. It's better than most sex!
For the SQL Server Management Studio, can use it read only a little and otherwise just can't make sense out of most of the screens, windows, sub-windows, check boxes, terminology, concepts, etc.
So, for SQL Server administration, just back to the simplest little SQL statements, mostly industry standard.
The SQL Server documentation of users, logins, etc. wins the prize for the worst technical writing I ever saw. But, do some Google searches, go to some Web sites, and see that just some fairly simple SQL statements are enough for such administration work. So, get a collection of little SQL files, run them through the wonderful, fantastic, we're lovin' it, SQLCMD.EXE, document the little files and their usage, and, fine -- f'get about Management Studio.
Basically, right, really prefer command lines to GUIs! GUIs? Far too difficult to understand, get to work, script, document, etc. We'll let the cognitive psychologists at Xerox PARC, Steve Jobs, etc. play with direct manipulation GUIs, and we'll stay with command lines, scripts driving command lines, and a text editor writing the scripts. Sorry 'bout that. To each their own. If you like GUIs, then go for it. YMMV.
WPF? Maybe that boils down to Windows Forms for a native Windows application, but our only GUI is HTML and CSS with the little JavaScript ASP.NET writes for us. If WPF boils down to HTML elements, then, sure, we'll just use, directly, HTML elements and/or the ASP.NET class wrappers for those elements to make the HTML programmable, that is, be able to generate HTML elements via software that executes for each user uniquely after they connect.
So, we just saved having to read some hundreds of Web pages at MSDN, buy a cubic foot or so of books, do 500 Google searches about details, submit 100 questions to Stack Overflow and the MSFT fora, etc.
Our code so far is about 30 KLOC (that is, actual VB statements) with maybe 60 KLOC of blank lines and 100 KLOC of comments.