C#揭密II（大師們在說些什麼？） (轉)[@more@]
揭密II（大師們在說些什麼？）
先宣告這篇文章屬於收藏性質的,推薦給那些喜歡技術的愛好者。
這之前我曾轉載了O'Reilly的一篇關於C#的訪談錄。O'Reilly一向以技術和評論公見長，他們的編輯一般都有著很深的技術背景和功力(所以出的書也比較貴haha)，所以那篇著重整個流行技術，有不少是和相關的；而這一篇都是MS內部的幾個高手在交談，涉及的範圍比上次的專訪要廣，裡面有一些很新奇的術語和許多問題的觀點。另外我認為這篇文章對以前非常熟悉COM+、和Window DNA（N 層結構）的人目前評估和思考向新的dotNET體系遷移都很有幫助。
Anders Hejlsberg是個很奇怪的人，從他身上你感覺不到一個語言創始人那種對某種語言偏愛的狂熱，卻很容易感覺到他所透露出的那種對技術對程式語言的堅定和深厚理解。很喜歡他在上一篇訪談錄中說的一句話：“Language is a funny thing: It's a matter of taste. Language is almost a religious thing, and it's a lifestyle choice for programmers。”不過我知道這句話說的不是他自己。這篇文章中還有好些人：Brian Harry，Peter Golde ，tt Guthrie（ASP老怪），Mark Anders。有了這些人，有福啊。
小氣的神
2001.09.24
Conversations on:namespace prefix = o ns = "urn:schemas-microsoft-com::office" />
Derived from on-line chats with our early adopters, a series of conversations with Microsoft engineers, designers, and developers look at issues involving C#, , and the Common Language Runtime.
Summary: What follows is a series of conversations with Microsoft engineers, designers, and developers, looking at issues involving C#, ASP.NET, and the Common Language Runtime. (10 printed pages)
A Conversation with Anders Hejlsberg and Peter Golde on C#
Anders Hejlsberg is a Distinguished Engineer in the Developer Division at Microsoft Corporation. He is the chief designer of the C# programming language and a key participant in the development of the .NET . Previously, Anders was the architect for Visual J++ and the Foundation Classes.
Peter Golde is a Software Design Engineer in the Developer Division at Microsoft Corporation. Peter has worked on development tools at Microsoft for over 10 years, contributing to products such as Microsoft C, OLE Automation, , Visual Basic for Applications, and Visual J++.
Q: Peter, you attended the ECMA meetings in March. Can you disclose anything about what's going on there that is new?
Peter Golde: Sure. As some of you may know, Microsoft, , and HP jointly submitted two specifications to ECMA for standardization via the ECMA process. These two specifications are the C# language and the common language infrastructure (CLI), which is a subset of the .NET Framework. We're meeting with a number of companies every month as part of the standardization process. It's difficult to predict the schedule with absolute certainty, but we hope that ECMA will be able to complete standards for both parts by the end of 2001.
Q: How does the CLI compare to the CLS and the CTS?
Anders Hejlsberg: CLS stands for Common Language Specification, CTS stands for Common Type System. The CLS is a specification of what features any programming language implemented on the .NET platfomust support.
Q: OK, the CLS is less than the CTS. Where does the CLI fit?
Anders Hejlsberg: The CTS is basically another for the type system in .NET, i.e. a specification of what a class, struct, enum, or such is. CLI is really just another word for the large subset of the .NET Framework that we submitted to ECMA.
Peter Golde: The CLI includes the CLS and the CTS.
Q: Anders, after your work on Turbo Pascal, , Visual J++ and now C#, how do you see programming languages evolving today?
Anders Hejlsberg: Jeeez, had to ask an easy one, eh? I guess I'm becoming less and less of a believer in revolutionary approaches to language design. It really is amazing how much the capabilities of computing have evolved, yet we're basically still using the same kinds of programming languages. It gives me hope that we can go even further with an evolutionary approach where we don't just invalidate all the work that went before.
Q: Have you thought much about moving toward an intentional programming model?
Anders Hejlsberg: Can't say that we have. As I see it, one of the problems of intentional programming is that you're basically creating a new programming language for every ain specific application. I really am more of a believer in having a core set of abstractions (such as classes, methods, properties, and events) and then applying them in each domain—but in a way that preserves familiarity.
Q: Customers looking at the .NET Framework for their application development efforts have asked whether or not the common language runtime (CLR) is a virtual machine (VM), and if so, what limitations or penalties associated with VMs (performance and so forth) will folks need to consr in their efforts?
Peter Golde: Yes, I think that the CLR can be considered in the broad class of things that one might call a VM. As to performance, though, I don't think that this classification says much of anything interesting about performance. You should judge performance by measuring performance on the applications that you are interested in. Don't try to prejudge performance based on your preconceptions about what will and won't be slow—just test it!
Q: Peter, are there any kind of applications that you would explicitly not build on the CLR due to issues with running managed versus unmanaged code?
Peter Golde: In terms of what applications I wouldn't write, I would say that "hard real-time" kinds of programs probably wouldn't be a good fit (at least right now), because we don't make very strong guarantees about the garbage collector, things like robot control and the like. There are real-time friendly garbage collection algorithms, so I don't think this would be a limitation forever.
Q: Can you discuss any advantages C# would have over Visual Basic (VB) in terms of the framework?
Anders Hejlsberg: Regarding C# vs. Visual Basic, it really primarily comes down to what you already know and are comfortable with. It used to be that there was a large perf difference between and C++, but since C# and use the same execution engine, you really should expect the same perf. C# may have a few more "power" features (such as unsafe code), and VB.NET may be skewed a bit more towards ease of use (e.g. late bound methods calls), but the differences are very small compared to what they were in the past.
Q: Ok, can you contrast C# with VB.NET? Questions usually come in the form of "I know you guys say VB.NET and C# let you do the same thing, but C# was designed for the CLR, so I don't believe you when you say VB.NET is just as good."
Anders Hejlsberg: Regarding C# versus VB.NET, the reality is that programmers typically have experience with either C++ or VB, and that makes either C# or VB.NET a natural choice for them. The already existing experience of a programmer far outweighs the small differences between the two languages.
Q: It has been said a few times that C# is the language designed for the CLR. Considering that all the languages that Microsoft will shwith the VS.NET will be able to target all the features of the CLR, what makes C# more CLR "friendly" than the other?
Peter Golde: I don't think that C# is necessarily any more friendly to the CLR than other languages. The CLR has been designed to be accessible via multiple languages. However, you will probably find that C# is more strongly focused on the CLR than other languages like C++, which have a number of other facilities that are less oriented toward the CLR. By designing C# in conjunction with the CLR, we have the "luxury" of not having backwards compatibility constraints.
Q: Is there any difference between the DEFAULT Equals function (implemented in ) and the =?
Anders Hejlsberg: For two reference types (classes), the default Equals() method is the same as ==. But for value types (structs), there is no == operator unless you provide an implementation in the value type.
Q: Is Lock (this) similar to the synchronize key word in Java?
Peter Golde: Yes, lock () is extremely similar to synchronized () in Java. We don't support the notion of a modifier on methods, because our experience is that it leads to deadlock or poor performance in too many cases.
Q: We mostly want the COM+ benefits of memory caching, independent process space, etc.; we don't need to worry about database transactions. Is this a valid reason to place CLR components into COM+, or is it better to just let the CLR handle it?
Anders Hejlsberg: I would look at .NET Application Domains and not use COM+ in that case.
Q: Can you elaborate on .NET Application Domains?
Anders Hejlsberg: Sure. An Application Domain is sort of like a light-weight process. Two application domains will share the same GC heap, but the CLR provides automatic and transparent marshalling between the application domains. It allows you to protect light-weight processes from each other without taking the fairly large overhead of an process.
Q: Is the Application Domain a similar concept to the Java Package?
Anders Hejlsberg: No, a Java Package is a different thing. The closest analogy in .NET is an assembly.
Q: What are the plans to allow C# code to run on a PocketPC?
Peter Golde: We've announced that we'll have a ".NET Compact Framework" that will be optimized for portable devices. Obviously there are limitations in terms of the scope of the class library, memory limitations, and so forth compared to the desktop or server. I should add that one of the focuses of the ECMA standardization work is to standardize a library framework that is appropriate in size and scale for portable devices. There is obviously a large amount of interest in this from many companies.
A Conversation with Mark Anders and Scott Guthrie on ASP.NET
Scott Guthrie co-founded the ASP.NET Team and leads the design team responsible for architecting the product. His individual technical contributions include: ASP.NET Forms Page Architecture, ASP.NET Web Services Infrastructure, ASP.NET Compilation System, ASP.NET Distributed Session State Infrastructure, ASP+ Deployment Architecture, ASP.NET Reliability System, and the ASP.NET HTTP Runtime Architecture. Prior to ASP.NET, Scott was a member of the and teams.
As the Microsoft Product Unit Manager of the .NET Framework, Mark Anders leads the team that designs and develops the .NET Framework, including ASP.NET, Windows Forms, Base Class Libraries, and other class libraries. Prior to this, he co-founded the ASP.NET team and held lead positions in program management as well as development.
Q: Scott, Mark, if you had to pick one thing, what do you think is the single coolest developer feature of ASP.NET?
Mark Anders: Well, I'll tell you the feature that gets the most applause: it's tracing! Seriously, it's almost a spontaneous standing ovation. One guy who I showed it to said that it was "the coolest thing I've ever seen." (Note, I wouldn't go that far!) Actually, my favorite feature is server controls.
Scott Guthrie: I think the partial page output caching feature that we are going to ship in Beta2 is probably the coolest developer feature, because it can dramatically impact the performance of literally any site. The xcopy deployment features (no restart on DLL updates) we have I think also are pretty close.
Q: Tracing is a great feature. One of the questions we get a lot: is there any penalty for having all the tracing code but turning it off when going into production?
Scott Guthrie: There shouldn't be any noticeable performance difference when tracing is turned off (but code left in). One thing to keep in mind, though, is that if you have expensive "trace calculations" that you output as part of tracing, then you should scope it within an "if (Trace.Enabled = True) Then" block. When tracing is turned off, "Trace.Enabled" will return false
Mark Anders: Note that we don't gather all of the statistics if trace==false.
Q: Could you discuss the security of the config files. I have seen a lot of concern that since they are simple XML files, they can be ed into easily.
Scott Guthrie: We do block all access to the config files from remote users. However, I think the concern people have is whether a rogue user who gets access to the config file can modify and take over things. Note that this problem exists with ASP today as well, in that the metabase s can be written to, which would effectively do the same thing. However, there are some things that you can do to reduce this problem. Specifically, with ASP.NET we support the ability to "lock down" settings at a parent directory. For example, you might want to lock down the security identity of the worker process (i.e.: the username it runs under) at the machine level and then restrict sub-applications' abilities to override it.
Q: I see confusion as to whether to mimic the Windows DNA model by creating ASP Presentation interfaces talking to COM+ components, or in the .NET era to just write code behind and stick Dynamic Link Libraries (DLLs) in the BIN and be done with it.
Mark Anders: I would say that services provided by COM+ are still required if you want transactions. However, the model of using Dto put components on another box and scale out that way is not recommended.
Scott Guthrie: In general I would recommend continuing to logically partition your application code (which was one of the things Windows DNA suggested). For example, putting all of your data access logic within modular classes that you then call them from pages—like we do from the IBuySpy applications. ...In general, you shouldn't use COM+ transactions unless you are actually doing distributed transactions across multiple data store machines. If you are just updating a single database, then leverage the transaction capabilities within it.
Q: What if you are planning on using remoting to communicate between our first and middle tiers, and you've only gotten C# working? Are there any known issues today with using remoting to communicate from ASP to Visual Basic (VB)?
Scott Guthrie: There shouldn't be any problems doing remoting from VB (like C#), although you should be a little careful about how to use remoting. In many cases it is best not to do the extra network hop. There is a big performance penalty to going to the other machine, so you shouldn't look to do it for either performance or scalability reasons. It does make sense if you are connecting to a different application or data center, where for org/technical or political reasons you need code to run elsewhere.
Q: What if you want to use it to communicate from Web servers that are hosted at an outr across a back to the network where the databases are? For security reasons, we won't put the database out in the DMZ.
Scott Guthrie: One other possible solution you might also investigate for that would be to leverage ISA (Internet Security and Acceleration) server, where you would put ISA in front of the firewall, and then ASP.NET and the database behind it. We actually just finished doing some benchmarking numbers with that solution and saw really great results. It is also really easy to set up and administer, and might be easier to ultimately deploy and manage going forward. One nice thing about ISA is that it doesn't require any ASP.NET code changes to leverage it, so it is pretty easy to try out and evaluate.
Q: Could you comment on interoperability (via Session Objects, Query Strings, etc.) between ASP and ASP.NET? Any gotchas?
Mark Anders: There are a few. First, we've made the object models as close as possible. However, if for example you store COM objects (not new CLR objects) in sessions, and you want those to be out of proc, they won't work. You need to have new objects that can be serialized. One thing to note is that ASP and ASP.NET will run side by side on a box, because at an application level ASP and ASP.NET do not share sessions.
Q: I've seen a lot of concern that data can be passed page to page (ASP to and from ASP.NET).
Mark Anders: Since we really use standard Web techniques, passing info page to page should not be a problem. However, page to page in ASP and ASP.NET typically assumes services that are provided by each, such as session and application state. These services are not shared, and so you can't rely on them.
Scott Guthrie: I have a list of things you can do to ease migration of ASP code to ASP.NET.
1. Use only a single language within the ASP application. Don't intex and together in the same page (in general a bad programming practice with ASP, but also a migration issue for ASP.NET in that we now require only one inline language.
2. Explicitly declare all of ASP page functions within a