Slashdot Mirror


Understanding .NET: A Tutorial and Analysis

benjiboo writes "This is one of the many books designed to help the average technical manager or developer get a feel for what the .NET framework means for them. Primarily geared towards developers and technical managers, this book aims to cut through the marketing hype. But, does it succeed? Read on for Benjiboo's answer to that question. Understanding .NET: A Tutorial and Analysis author David Chappell pages 288 publisher Addison-Wesley rating 4 reviewer Benjiboo ISBN 0201741628 summary A summary of the .NET framework

Firstly, this book doesn't attempt to act as a programming tutorial, and as a result is thin on code examples. Instead, the book takes a highly summative approach to the main technologies of the framework, broadly dividing them into: web services, the CLR and languages, the class library, data access, ASP.net and .NET my services.

Having said this, the central theme through the book is that of XML and web services, accurately reflecting their importance in the .net framework. It frustrates me how web services are often described as revolutionary, when built on technologies such as UDDI and WDSL which in turn are based on relatively mature technologies such as XML and HTTP. This book falls into the same trap of pandering to the hype surrounding web services, without really managing to convince me of what is so revolutionary about them.

The author dedicates a chapter to a summary of the main .NET languages, Visual Basic .NET, C#, and the managed extensions of C++. The author concludes that "Managed C++ adds even more complexity to an already complex language." Some may have reservations with this statement; garbage collection, interfaces, attributes and the managed types are only likely to result in less work for the developer even after a relatively short learning curve. The author appears to come out in favour of C# over the "more complex" Visual Basic. I would like to have seen some discussion on other .NET languages under development.

The chapter on the class libraries makes a relatively good job of summarising the massive .NET libraries. It's a fleeting overview of the most useful and interesting parts of the libraries. Remoting (remote method calls), reflection and the ubiquitous GUI libraries are just a few examples. This is one of the stronger sections of the book in my opinion, though this is coming from a developer's perspective.

There is a concise chapter on ADO .NET. The author acknowledges the fact that this is the latest in a long line of Microsoft data access libraries but fails to indicate why this one is better. The controversial .NET My Services is also detailed. The book doesn't really ponder the politics surrounding My Services, which is surprising as this element was always likely to be its downfall.

In parts, this book is overwhelmingly pro-Microsoft. In a particularly gushing moment, the author implies that COM was successful in its goals of interoperable component software, only failing to reach critical mass due to a failure by other vendors to support it. OMG's corba on the other hand was based on an incomplete standard, destined to failure due to Microsoft's decision not to support this 'doomed' standard. I would whole-heartedly disagree with this. Firstly, the distributed object technologies of CORBA are applicable to a different range of problems. Even overlooking the validity of this comparison, CORBA has seen massive support and is generally considered to be more successful than COM.

On a more positive note however, this book does provide isolated moments of insight. Some of the sidebars, for instance, tend to delve a little deeper, providing a little bit of the insight I was hoping to gain by reading this book. A brief look at the differences between MSIL and Java's VMs for instance led me to research further. Apparently future versions of SQL server are set to host a version of the .NET CLR natively, similarly to how Oracle 9i can run its own Java VM. For me, these insights go beyond the information which I could have picked up on any number of white-papers out there on the net.

In hindsight this book is perhaps too shallow, falling into the trap of using a barrage of acronyms and buzzwords without delving deep enough into any one topic. There is no mention of cross-language interoperability, and more importantly no mention of cross platform interoperability efforts -- which do exist. Also, even with a book so Microsoft oriented, I would expect to see either a distinct section, or at least more comments, on the pitfalls and barriers to takeup of the framework. A more critical and less Microsoft-centric text would for me have made this book more authoritative.

Table Of Contents

Preface
1. An Overview of .NET. 2. Web Services.
3. The Common Language Runtime.
4. .NET Languages.
5. The .NET Framework Class Library.
6. Accessing Data- ADO.NET.
7. Building Web Applications- ASP.NET.
8. .NET My Services.
Conclusion

You can purchase Understanding .NET: A Tutorial and Analysis from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

12 of 282 comments (clear)

  1. Re:well by xyzzy · · Score: 5, Interesting

    Not particularly any more or less than any other Microsoft technology. In fact, if you do any Microsoft-centric work in your shop, .Net is a significant improvement over (COM | ASP | etc). If you live for cross-platform portability, you won't be using any of these anyway.

  2. Re:Let me get this straight.. by Otter · · Score: 5, Interesting
    I think what he means (as opposed to what he says which, you're right, makes no sense) is that he wanted the book to be more even-handed about the downside of .NET, and less cheerleading.

    At any rate, this book does sound potentially useful. It's a year (two years?) since .NET was introduced and every .NET story here still has multiple +5 posts asking "Could someone finally explain what the hell .NET is?", each responded to by multiple +5 posts providing barely overlapping explanations. Good for karma, I guess, but so far the only value I've gotten from .NET is the KDE theme copying it.

  3. No how long SOAP changes... by MosesJones · · Score: 4, Interesting


    To break Microsoft... actually this is EXACTLY what the next spec does. Microsoft were the only people who went for literal encoding, which is a bit naff. The next SOAP spec does away with literal and enforces the use of RPC encoding.

    So actually this standards adherence stuff is already biting MS. But to compete in the enterprise space they have to adhere. Mono however is screwed.

    --
    An Eye for an Eye will make the whole world blind - Gandhi
  4. Re:How many languages? by Anonymous Coward · · Score: 1, Interesting

    >> Java.NET (hey, it could happen)

    Already happened. It's called J#.

  5. Should be named "gotCaught" instead ;-) by Anonymous Coward · · Score: 1, Interesting

    Funny that MS & MS affiliates still can write a whole spec of a brand new platform that clone 99% of Java specs, not using a single time the word Java ;-)

    Now, that everybody but fools know that dotNet is somehow Java cloned ... MS try to yet and again let people forget about the fact that MFC/VB/MTS/... are nothing but dead !

    MS skilled people are now asking if they should go to dotNet or Java. IF you are an independant, then you may have the lead over the choice. But if you are in a firm, this choice will be made for you by IT "polliticians".

    For those who embraced Java since early years, dotNet is no fear at all has it do not change anything in way of thinking and building softwares.

    But if you were a MS tied, now you are in trouble, because you are forced to make you object revolution ! Move or die in other words.

    Big Enterprise solutions will certainly became more and more Java centered, just because investissment have already been made ! And IT leaders in order to keep ROI low, will keep away from having 2 competing platform on the same architectures.

    Let's face to reality, there are no reason at all for a Java architecture to change to dotNet.
    But they are tons of reason for an old tech MS-architecture to migrate to a Java platform ...

    MS has triggered the platform revolution, but they may have sign their worst act since ever !

    Because, MS still think that by damaging Sun they could slow Java market impregnation. But Java is no more lead by Sun anymore ! But the community does ... too late MS ;-)

    All is a mater of time ...

    And time is ticking !

    LLO

    PS: For those who said that xbox will be a "huge success" or the "best success story for ages" ... they may now have a bit of a problem, isn't- it ;-)

    PS2: Do you think that MS realy thought they could damaged Windows domination with dotNet or are they just S&M fans (with spikes and stuffs related) ?

  6. Re:How many languages? by bimmergeek · · Score: 2, Interesting

    I attended a MS .NET Visual Studio launch event last spring/summer. During the session, which was led by a knowledgeable and articulate MSite, we were informed that the code compiled by Visual Studio is not executable code but an intermediate language.

    The executable code is actually generated on demand on the server side by a just-in-time compiler using the .NET framework resident on the server. The framework determines the hardware and optimizes the code for the server.

    The implications of this structure were that there are no longer any advantages to be gained over coding in C# instead of VB because both compile the same intermediate code from Visual Studio. What could only be done in C# can now be done in VB.

    The presenter said (almost an exact quote here): "In the past, programmers said, 'I'm a C guy,' or 'I'm a VB guy.' Now that .NET Visual Studio has equalized these two languages through the intermediate language and the JIT compiler, C# and VB will simply be syntactical preference. People will now say 'I'm a .NET guy.'

    --
    -Everyone laughs at lemmings but no one ever wants to admit to ever being one.
  7. Re:How long? by bbqBrain · · Score: 2, Interesting

    Because hiring managers often don't know much about the technology their departments use. For instance, I saw listings in 2000 for people with 2-3 years J2EE experience...uh, sure some people qualify, but they all work in Sun R&D.

    I think it's just a ploy to keep the really inexperienced would-be applicants from wasting the employer's time.

    --

    One of the reasons that I became a lawyer was to avoid ever having to hire one. -SPYvSPY
  8. Re:How many languages? by russianspy · · Score: 3, Interesting

    That's not entirely true. There are languages that simply will not map well enough onto the .NET platform. I know of one for sure - Python. There is simply no way to make a natifve implementation of Python.NET - some things like dynamically binding functions to an object instance, multiple number of function arguments, etc will not work. There is a version of python for .NET, but it involved porting over the INTERPRETER onto .NET and running that. Basically you have a VM running a VM running your code. If you think that is not very fast - you're right ;-)

  9. Re:Slightly Offtopic by nicodaemos · · Score: 2, Interesting

    You're right that Microsoft has patience where others do not, but they've only ever succeeded where they've been able to create a legal/illegal choke point in distribution or had marginal (only compared to their monopoly products) success in products which are closely linked or can leverage their monopoly products.

    I may not know enough about their plans, but I don't see the distribution choke point in gaming. The best bet is trying to buy the biggest game developers - which is what Microsoft appears to be trying to do - but even then, a new game developer can come out of nowhere and write a hit game for your competitor's platform. It's just so unpredictable compared to the controlled windows distribution scheme with the OEM's.

    I actually think Microsoft has a better chance with the home media market with their close ties to the RIAA and MPAA due to DRM technology. The RIAA is intimately aware of the power of choke points on pricing and profit. There was never a question about whether they and Microsoft would get into bed .... the only question was which one would have to sleep in the wet spot.

  10. Lots of reasons why I want .NET to fail by Anonymous Coward · · Score: 5, Interesting

    This note was originally published at John Munsch weblog on January the 14th.

    Lots of reasons why I want .NET to fail and fail badly

    It's benefits a criminal organization. Not one that's been found guilty of crimes once or maybe twice, but lots and lots of times. Those crimes are many and varied, but here's just a few of them: Stac Electronics v. Microsoft, DOJ v. Microsoft, Sun v. Microsoft.
    P.S. If you want to split hairs, Stac v. Microsoft isn't a criminal action, it's doesn't stem from a criminal abuse of their monopoly like the other two cases. Instead it was just a case of a small company being driven out of business by willful patent infringement, theft of trade secrets, etc.

    Microsoft isn't just one thing anymore. It's too damn big for that. I'm sure even Bill himself knows better than to think that he truly controls the whole ship because it's become big enough that he can't possibly know all the projects, people, etc. anymore. But even a really large company still has a kind of collective personality that it exudes and a large part of the personality both internal and external to Microsoft for many years now is that of a total control freak.
    If they don't own it, if they don't control it, if they didn't create it, if it doesn't have a broad stamp from Microsoft on it, then they don't want it. Sometimes it's sufficient for the thing to merely exist and they'll refuse to acknowledge it, other times they need to actively stamp it out because they can't control it.

    When was the last time you can remember Microsoft saying they supported a standard? That is, not something they invented and submitted a RFC for, an actual, take it off the shelf and re-implement it without renaming it or "improving" it so it doesn't work with anybody else standard. C++? Basic? HTML? A video or audio codec? Java? Anything?

    I'm sure there's something, somebody will point out their excellent support for TCP/IP or something and I'm sure that's true. But if you were to look at Microsoft as a person in your life, you'd wonder what was wrong with him or her such that so much had to be controlled by that person.

    When your business is selling the operating systems that 90+% of everybody uses, software development tools should not be a profit center.
    Why should I have to plunk down a couple of thousand dollars for a "universal subscription" in order to have access to compilers and basic development information? Sun doesn't have to do that? On this point I'll quote from the .NET "rebuttal" that I linked to above, "For non-profit use VS.NET can be had pretty cheaply, especially if you know anyone that is in college somewhere." Pretty cheaply? For a non-profit (that means charities, churches, universities, the hobbiest who is going to give away his work for FREE)... pretty cheaply? Wow. That is well and truly pathetic. To try and justify it, and say, oh well, you can try to scam an educational discount so it won't be so dear, is even more pathetic.

    Marketing. Have you been "lucky" enough to catch one of the .NET commercials with William H. Gacy telling you how great it is without really ever telling you anything about it? Microsoft doesn't trust .NET to stand on its own technical merits and it knows it may go like cod-liver oil down the gullets of a lot of people who have seen how the company works behind closed doors even if it were the tech shiznit.
    So they are going to pull a page out of Intel's bum-bum-buh-bum "Intel Inside" playbook and try to sell the brand like it's sneakers and cola. Trust us, you'll look cool if you use it, and we'll keep hammering the brand on TV so somebody who doesn't have much tech savvy in your organization will ask you if you are using it, or have plans to port to it, or whatever, even if he hasn't got a clue what "it" is in this case.

    They don't trust you. They don't like what they can't control and they can't control you. They can try and they always will keep trying but ultimately you are going to see them keep trying to do things and always keep a step towards the door just so they can bolt if they have to. Want to see what I mean? Go visit GotDotNet sometime if you haven't already been there. It's the grassroots community website that Microsoft put up to support .NET just in case there wasn't any grassroots community who actually wanted to do it. Or maybe just in case there was and they couldn't control it.
    Ever been to SourceForge? Of course you have, everybody has because that's one of the hubs of all open source projects. You can go there and get the source of thousands of cool open source projects and it really serves the community well. There's even hundreds of projects now that list C# among their programming languages. So why did Microsoft feel compelled to create their own GotDotNet Workspaces that is clearly just a ripoff of SourceForge?

    A few reasons are fairly clear: First, at many of their workspaces you don't get in unless they know who you are. Ever been stopped at SourceForge and asked for a name and password to look at a project? What about download binaries or source? No? At GotDotNet you will, lots of projects are marked with a lock. Second, forget about all those messy licenses that Microsoft might not approve of, you don't need to worry your little head about BSD vs. GPL vs. LGPL. You've got the one true workspace license that you have to agree to, or else you won't be putting your project there. Lastly, well it's kind of obvious, but it's really all about control isn't it. After all, if you aren't under their thumb, that has to be a bad thing. So a SourceForge that they control is pretty much a requirement, isn't it?

    It's a really sad way for a lot of people to waste a whole lot of time rebuilding that which already exists. Wouldn't the whole computing world be a lot better if there wasn't a team of people, maybe a couple of teams of people building complete copies of .NET for other platforms? If those same people were working on giving us new libraries and new tools for an already existing language instead of pouring in the thousands of man hours it's going to take to build a copy of the C# compiler or a .NET version of Ant and JUnit?

    In the end, we'll all just be left with another way to do the exact same thing only in a different language. Lord knows the world benefits now from being unable to share media between France, Germany, Italy, Spain, the US, and Japan because we can't all speak the same language. I benefit every day from the fact that I can't read a Japanese manga I might enjoy or understand a TV show from Europe. Once you are done building this tower, go build a few more right beside it using Perl, Python, and Ruby too. They're all trailing behind in certain areas, we need to make sure the same set of stuff is reinvented and rewritten for all of them too.

  11. Re:What did you expect? by GroovBird · · Score: 3, Interesting

    I heard him speak at the .NET convention in Brussels last friday! He did an introductory peptalk in front of the entire audience, and then spoke at a session about the differences between .NET and J2EE.

    Well, even though even lunch was paid for by the .NET campaign budget, he really didn't step over the edge by spreading FUD or anything like that. It seemed quite honest and unbiased.

    (Allthough he DID call Linux nothing more than a broken light instead of a real fire, but that was another session.)

    But he writes mostly books about Microsoft technologies and not very deep ones at that...

    I also don't agree with the reviewer's thoughts on the success of COM. COM was a successful piece of crap, but you wouldn't hear about it if you weren't in the Microsoft camp.

    Dave

  12. How people posting have used .NET? by Anonymous Coward · · Score: 1, Interesting

    Of all the posts, how many people have actually tried to write complex applications with .NET? I don't mean doing a simple ASPX page that displays simple rows from SQL Server. I mean creating a pool of objects or using ThreadPool to perform some heavy weight process. For example, say you have a sophisticated shopping cart system that has built in personalization. You want the server to preload some applications when IIS starts up. How do you load presets and have them behave in a persistent manner? Do you use global.asax and application start to contain that logic? Is there a standard mechanism that allows for management of those persistent objects while the server is running? How do you get around the fact ThreadPool is limited to 25 threads? What happens if you exceed 25 threads? Is it desirable to have ThreadPool of ThreadPool? Do you manage delegates in those situations to make sure you don't over synchronize, but still make sure you get the right data out? All those saying how great .NET is haven't really tried to implement complex applications with life-cycles that aren't request/response oriented. Saying Biztalk is where that stuff might go, doesn't count, since it's not out yet.