We're currently architecting an enterprise Windows app using WCF.  However,
now with LINQ, we're planning to re-architect that way instead.

I've prepared the below in an attempt to explain/sell the new approach to
our team.

Any feedback would be greatly appreciated.


Early 90's: fat clients
- technology not "normal" for distributed computing


Late 90's: thin clients
- technology available to do it (DCOM, other)
- client hard drive space EXPENSIVE
- computing power of client PCs WEAK
- single place for business tier desirable
- pushing updates to many clients cumbersome


2007: full circle (back to the fat client)
- client hard drive space CHEAP
- computing power of client PCs STRONG
- ClickOnce makes pushing updates to clients EASY


LINQ instead of WCF pros:
- better performance/faster
- one push (ClickOnce) to client covers changes to service (business code)
too
- No need for all developers to have Team Database (since no procs, only
schema)


LINQ instead of WCF cons:
- if huge amount of data to crunch in the business tier with small result
set to be passed back to client, having business tier on server (closer to
database server) would be better since sending huge data across network to
the client would be a performance issue
- if hard line between developers and DBA (large shops), then would probably
want to use LINQ to procs so DBA can maintain control


Thanks,
Ron

Ronald S. Cook <rc***@westinis.com> wrote:
You make it sound like LINQ and WCF are alternatives to each other -
they're not. It's like saying, "We were going to use SQL Server, but
now we're going to use a web application."

WCF is a way of communicating with services.
LINQ is a set of technologies around querying data, whether in a
database or elsewhere.

The two just don't compete.

You're right, thanks.


Show quoteHide quote

Read Stream Until Bytes Hit?
My own version of replace
events (forms)
Needing info on passing data between applications. Win[C#]
modifying a string array via MFC COM Interop