C# 5.0：构建Windows 8 Metro与桌面应用的开发指南

1星 | 下载需积分: 50 | PDF格式 | 4.22MB | 更新于2024-07-24 | 53 浏览量 | 举报

《C# 5.0编程：构建Windows 8 Metro Web与桌面应用》是一本由O'Reilly Media于2012年3月13日发布的书籍，它专注于使用C#语言开发适用于Windows 8平台的新型应用程序，特别是针对平板电脑上基于触摸的交互设计的Metro风格应用。C#语言自问世以来，一直是Windows开发的核心，随着Windows 8的推出，它作为主要支持的语言之一，与C++、JavaScript和Visual Basic一起，被选为开发这些新式应用的主要工具。 C#语言由微软开发，但其规范是由标准化组织ECMA制定和文档化的，这意味着任何人都可以根据ECMA标准来实现C#。这并非仅仅是理论，开源项目Mono（http://www.mono-project.com/）提供了在Linux、iOS和Android等操作系统上构建C#应用程序的能力，展示了C#的跨平台适用性。选择C#的原因在于其广泛的应用领域。C#可以用于创建网站、桌面应用、游戏、手机应用以及命令行工具。与之竞争的其他语言各有优势，比如Python可能因其简洁性和易读性受到喜爱，而Java则因其强大的企业级支持而流行。然而，C#的优势在于其与.NET框架的紧密集成，特别是对于Windows生态系统的开发者，这使得它在性能、安全性、和.NET生态内的工具支持方面具有显著优势。 C#的特点包括面向对象编程、类型安全、垃圾回收机制、强大的类型系统以及逐步淘汰.NET 4.0框架，转向更现代化的.NET 4.5框架，这使得开发者能够构建更为高效、响应式且适应触控操作的Windows 8 Metro应用。此外，C# 5.0引入了新的特性，如动态类型和async/await语法，进一步提升了开发体验。选择C#是因为其丰富的功能、跨平台能力、与Windows生态系统的深度集成，以及随着版本更新带来的不断改进和创新。如果你需要开发高质量的Windows 8应用，或者希望利用.NET框架的优势，C#无疑是一个值得考虑的首选语言。

O’Reilly Media, Inc. 3/13/2012

Writing a Unit Test

Now I need to write a test. Visual Studio has provided me with a test class to get me

started in a file called UnitTest1.cs, but that’s not a very informative name. I need to call

it something else. There are various schools of thought as to how you should structure

your unit tests. Some developers advocate one test class for each class you wish to test,

but I like the style where you write a class for each scenario in which you want to test a

particular class, with one method for each of the things that should be true about your

code in that scenario. As you’ve probably guessed from the project names I’ve chosen,

our program will only have one behavior: it will display a “Hello, world!” message when

it runs. So I’ll rename the UnitTest1.cs source file to WhenProgramRuns.cs. This test

should verify that the program prints out the required message when it runs. The test

itself is very simple, but unfortunately, getting to the point where we can run the test is a

bit more involved. Example 1-1 shows the whole source file; the test is near the end, in

bold.

Example 1-1. A unit test class for our first program

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace HelloWorld.Tests

{

[TestClass]

public class WhenProgramRuns

{

private string _consoleOutput;

[TestInitialize]

public void Initialize()

{

var w = new System.IO.StringWriter();

Console.SetOut(w);

Program.Main(new string[0]);

_consoleOutput = w.GetStringBuilder().ToString().Trim();

}

[TestMethod]

public void SaysHelloWorld()

{

Assert.AreEqual("Hello, world!", _consoleOutput);

}

I will explain each of the features in this file once I’ve shown the program itself. For

now, the most interesting part of this is that it defines some behavior we want our

program to have. The test states that the program’s output should be the message “Hello,

world!” If it’s not, this test will report a failure. The test itself is pleasingly simple, but

the code that sets things up for the test is a little awkward. The problem here is that the

obligatory first example that all programming books are required by law to show isn’t

very amenable to unit testing of individual classes, because you can’t really test anything

less than the whole program. We want to verify that the program prints out a particular

message to the console. In a real application, you’d probably devise some sort of

O’Reilly Media, Inc. 3/13/2012

abstraction for output, and your unit tests would provide a fake version of that abstraction

for test purposes. But I want my application (which Example 1-1 merely tests) to keep to

the spirit of the standard “Hello, world!” example. To avoid overcomplicating my

program, I’ve made my test intercept console output so that I can check that the program

printed what it was supposed to. (Chapter 16 will describe the features I’m using from the

System.IO namespace to achieve this.)

There’s a second challenge. Normally, a unit test will, by definition, test some isolated

and usually small part of the program. But in this case, the program is so simple that there

is only one feature of interest, and that feature executes when we run the program. This

means my test will need to invoke the program’s entry point. I could have done that by

launching my HelloWorld program in a whole new process, but capturing its output

would have been rather more complex than the in-process interception done by Example

1-1. Instead, I’m just invoking the program’s entry point directly. In a C# application, the

entry point is usually a method called Main defined in a class called Program. Example

1-2 shows the relevant line from Example 1-1, passing an empty array to simulate

running the program with no command line arguments.

Example 1-2. Calling a method

Program.Main(new string[0]);

Unfortunately, there’s a problem with that. A program’s entry point is typically only

accessible to the runtime—it’s an implementation detail of your program, and there’s not

normally any reason to make it publicly accessible. However, I’ll make an exception

here, because that’s where the only code in in this example will live. So to get the code to

compile, we’ll need to make a change to our main program. Example 1-3 shows the

relevant line from the code from the Program.cs file in the HelloWorld project. (I’ll show

the whole thing shortly.)

Example 1-3. Making the program entry point accessible

public class Program

{

public static void Main(string[] args)

{

...

I’ve added the public keyword to the start of two lines to make the code accessible to

the test, enabling Example 1-1 to compile. There are other ways I could have achieved

this. I could have left the class as it is, made the method internal, and then applied the

InternalsVisibleToAttribute to my program to grant access just to the test

suite. But internal protection and assembly level attributes are topics for later chapters (3

and 15 respectively) so I decided to keep it simple for this first example. I’ll show the

alternative approach in Chapter 15.

Microsoft’s unit testing framework defines a helper class called

PrivateType, which provides a way to invoke private methods for

test purposes, and I could have used that instead of making the entry

point public. However, it’s considered bad practice to invoke private

methods directly from tests, because a test should only have to verify

the observable behavior of the code under test. Testing specific details

of how the code has been structured is rarely helpful.

O’Reilly Media, Inc. 3/13/2012

The file begins with a series of using directives. These are optional, but almost all source

files contain them, and they tell the compiler which namespaces we’d like to use, raising

the obvious question: what’s a namespace?

Namespaces

Namespaces bring order and structure to what would otherwise be a horrible mess. The

.NET Framework class library contains over 10,000 classes, and there are many more

classes out there in 3

party libraries, not to mention the classes you will write yourself.

There are two problems that can occur when dealing with this many named entities. First,

it becomes hard to guarantee uniqueness unless everything either has a very long name,

or the names include sections of random gibberish. Second, it can become challenging to

discover the API you need—unless you know or can guess the right name, it’s difficult to

find what you need from an unstructured list of thousands of things. Namespaces solve

both of these problems.

Most .NET types are defined in a namespace. Microsoft-supplied types have distinctive

namespaces. When the types are part of the .NET Framework, the containing namespaces

start with System, and when they’re part of some Microsoft technology which is not a

core part of .NET, they usually begin with Microsoft. Libraries from other vendors

tend to start with the company name, while open source libraries often use their project

name. You are not forced to put your own types into namespaces, but it’s recommended

that you do. C# does not treat System as a special namespace, so nothing stops you

using that for your own types, but it’s a bad idea because it will tend to confuse other

developers. You should pick something more distinctive for your own code, such as your

company or project name.

The namespace usually gives a clue as to the purpose of the type. For example, all the

types that relate to file handling can be found in the System.IO namespace, while those

concerned with networking are under System.Net. Namespaces can form a hierarchy.

So the framework’s System namespace doesn’t just contain types. It also holds other

namespaces, such as System.Net, and these often contain yet more namespaces, such

as System.Net.Sockets and System.Net.Mail. These examples show that

namespaces act as a sort of description, which can help you navigate the library. If you

were looking for regular expression handling, for example, you might look through the

available namespaces, and notice the System.Text namespace. Looking in there,

you’d find a System.Text.RegularExpressions namespace, at which point

you’d be pretty confident that you were looking in the right place.

Namespaces also provide a way to ensure uniqueness. The namespace in which a type is

defined is part of that type’s full name. This lets libraries use short, simple names for

things. For example, the regular expression API includes a Capture class representing

the results from a regular expression capture. If you are working on software that deals

with images, the term ‘capture’ is more commonly used to mean the acquisition of some

image data, and you might feel that Capture is the most descriptive name for a class in

your own code. It would be annoying to have to pick a different name just because the

best one is already taken, particularly if your image acquisition code has no use for

regular expressions, meaning that you weren’t even planning to use that Capture type.

But in fact it’s fine. Both types can be called Capture, and they will still have different

names. The full name of the regular expression capture class is effectively

System.Text.RegularExpressions.Capture, and likewise your class’s full

O’Reilly Media, Inc. 3/13/2012

name would include its containing namespace, e.g.

SpiffingSoftworks.Imaging.Capture.

If you really want to, you can write the fully qualified name of a type every time you use

it, but most developers don’t want to do anything quite so tedious, which is where the

using directives at the start of Example 1-4 come in. These state the namespaces whose

types this source file intends to use. You will normally edit this list to match your file’s

requirements, but Visual Studio provides a small selection of commonly used ones to get

you started. It chooses different sets in different contexts. If you add a class representing

a user interface control, for example, Visual Studio would include various UI-related

namespaces in the list.

With using declarations like these in place, you can just use the short, unqualified name

for a class. When we finally add the line of code that enables our HelloWorld example to

do its job, we’ll be using the System.Console class, but because of the first using

directive, we’ll be able to refer to it as just Console. In fact, that’s the only class we’ll

be using, so we could remove all the other using directives.

Earlier, you saw that a project’s References describe which libraries it

uses. You might think that References are redundant—can’t the

compiler work out which external libraries we are using from the

namespaces? It could if there were a direct correspondence between

namespaces and libraries, but there isn’t. There is sometimes an

apparent connection—System.Web.dll contains classes in the

System.Web namespace for example. But there often isn’t—the class

library includes System.Core.dll but there is no System.Core

namespace. So it is necessary to tell Visual Studio which libraries your

project depends on, as well as saying which namespaces any particular

source file uses. We will look at the nature and structure of library files

in more detail in Chapter 12.

Even with namespaces, there’s potential for ambiguity. You might use two namespaces

that both happen to define a class of the same name. If you want to use that class, then

you will need to be explicit, referring to it by its full name. If you need to use such

classes a lot in the file, you can still save yourself some typing: you only need to use the

full name once because you can define an alias. Example 1-5 uses this to resolve a clash

that I’ve run into a few times: .NET’s user interface framework, the Windows

Presentation Foundation (WPF) defines a Path class for working with Bézier curves,

polygons and other shapes, but there’s also a Path class for working with filesystem

paths, and if you want to write code that produces a graphical representation of the

contents of a file, you will need both namespaces, meaning that the simple name Path is

ambiguous if unqualified. But as Example 1-5 shows, you can define distinctive aliases

for each.

Example 1-5. Resolving ambiguity with aliases

using System.IO;

using System.Windows.Shapes;

using IoPath = System.IO.Path;

using WpfPath = System.Windows.Shapes.Path;

With these aliases in place, you can use IoPath as a synonym for the file-related Path

class, and WpfPath for the graphical one.

剩余285页未读，继续阅读

kanlaw0420

粉丝: 1
资源: 62

C# 5.0：构建Windows 8 Metro与桌面应用的开发指南

Programming C#5.0

Programming.C#.5.0(2012.10)].Ian.Griffiths.文字版

Programming C# 5.0

CSharp5.0 Language Specification

Programming CSharp3E

Wrox.Professional.Csharp.5.0.and.NET.4.5.1

Apress.Pro.Csharp.5.0.and.the.NET.4.5.Framework

[Professional.Csharp.5.0.and.NET.4.5.1(2014.2)]

Pro_CSharp_5.0_and_the_.NET_4.5_Framework_6th_edition

Csharp.5.0.in.a.Nutshell

最新资源