Resolving Very Slow Symbol Loading with VS 2008 during debugging
Recently, I was encountering insanely slow project loading times during debugging in Visual Studio 2008. Interestingly, this only happened while loading the project only in debug mode. Also, during the slow symbol loading time, the status bar at Visual Studio 2008 always showed Loading Symbols For ____.Dll .
To track it down, I enabled logging for the VS 2008 IDE. This can be done by adding the following entries to its configuration file.
1) Navigate to: C:/Program Files/Microsoft Visual Studio 9.0/Common7/IDE in Windows Explorer
2) Load devenv.exe.config in text editor.
3) Add the following entries into it
<system.diagnostics>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="myListener"
type="System.Diagnostics.TextWriterTraceListener, System version=1.0.3300.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
initializeData="c:/myListener.log" />
<remove name="Default" />
</listeners>
</trace>
</system.diagnostics>
As per this configuration, the trace log would be saved to C:/myListener.Log. Now I fired up VS 2008 and loaded to project in debug mode to reproduce the issues. I also ran couple of unit test cases in debug mode which were also not able to load. I opened the trace log and found these exceptions:
[V, 5820, 7, 2008/07/04 14:00:33.412] devenv.exe: DIA thew in retrieving symbols: System.Runtime.InteropServices.COMException (0x806D0005): Exception from HRESULT: 0x806D0005
at Microsoft.VisualStudio.TestTools.Common.Dia2Lib.IDiaDataSource.loadDataForExe(String executable, String searchPath, Object pCallback)
at Microsoft.VisualStudio.TestTools.Common.DiaHelper.GetSymbolsFileName(String imagePath)
Confirmed with the issue was related to loading of Symbols. I realized that I had once set up a dedicated symbol directory on machine at C:/symbols to enable debugging with WinDbg.
I checked the Debugging Options in VS 2008 to see if its trying to load symbols from somewhere else.
Then suddenly, I was reminded that I had once set up a environment variable _NT_SYMBOL_PATH to an Internet location while debugging in WinDbg to enable automatic downloading of symbols.
I originally thought that this setting was only applicable to WinDbg. But I was mistaken. In fact, this setting will be used across by all debuggers (atleast Microsoft debuggers). This is documented here . I was pretty sure that VS 2008 was trying to load symbols from the Internet location and since many of the assemblies in my application didn't had symbols were them, it must have been failing.
To confirm, I fired My Computer -> Properties -> Advanced -> Environment Variables and cleared out the line
_NT_SYMBOL_PATH=srv*c:/mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:/mysymbols
I reloaded the my project in VS 2008 in debug mode and Bingo, the problem was solved :)
While investigating this problem, I came across many other sources which could cause this issue , so I thought I can post it here for the benefit of community. The credit for these tips goes to Azeem Khan who is working with VSTS team at Microsoft.
- Make sure that you don't have a symbol path specified in VS under Tools | Options | Debugging | Symbols and also, that you don't have the NT_SYMBOL_PATH environment variable set on your machine.
- Verify that you haven't specified any network shares under the same setting to server that do not exist anymore. This will require timeouts.
- Specify a local cache for symbols under the same setting. After you have downloaded symbols once from network shares you can disable those locations. Symbol loading will go a lot faster after the first attempt.
- Do not specify any symbol lookup paths at all either in environment variable and specify paths in the options page but specify that they be used for manual loading. You can then manually load symbols for modules you care about either via the context menu in call stack or the modules window.
- VS 2008 SP1 has made a few improvements in this area. It allows for canceling loading of symbols as it is happening. This will allow you to get to your debug session much faster. Note that this is currently in Beta.
- Clearing the breakpoints also serve to solve this problem for some people.
解决方法：
通过分析发现问题是因为 Load Symbol 过慢造成的
将环境变量中的：
_NT_SYMBOL_PATH=srv*c:/mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:/mysymbols
键删除，并重新启动 VS2008 即可，因为此键的存在会使 VS2008 到此键中标记的地址去下载 Symbol ，而造成调试启动的极度下降。
我的情况：
通过查找，在环境变量中没有看到_NT_SYMBOL_PATH ，设置SYMBOL的字眼都没有。通过搜索，在C:/WINDOWS/Symbols看到有个DLL的文件夹，里面全部是pdb文件。将dll文件夹改名（因为对这些文件的用途不大了解，删除是不可恢复，所以改名避免删除导致其他错误 ），然后重启VS2008就OK.
无论是从用户的角度来看还是从开发人员的角度来看，Windows Phone 7给我们带来众多的新的和令人振奋的功能。与此同时，当前的Windows Phone 7系列也的确存在令许多用户失望的缺憾。一个代表性的遗憾便是，Windows Phone 7缺乏本地数据库API支持—当前的Windows Phone 7操作系统仅提供通过XML、客户端独立存储和云存储等几种有限的数据访问支持。那么，就本地数据库功能来说，我们真的有没有其他的选择了吗?当然不是这样。如今各种开源社团如火如荼，已经有一些开发人员和团队一直努力在填补这一方面的空白。
请注意，尽管目前已有多个尝试实现了Windows Phone 7本地数据库支持，但最后，这些系统都需要运行于Windows Phone 7提供的独立存储基础之上。在本系列文章中，我将向你介绍上述成员之一-Sqlite Client for Windows Phone。这是一种新的，功能强大且易于使用的Windows Phone 7本机数据库解决方案，该系统公布于著名的开源网站CodePlex。篇幅所限，我仅介绍在Windows Phone 7系统中使用Sqlite Client for Windows Phone编程的部分技巧。
[备注]本系列文章中的案例程序调试环境包括：
1. Windows 7;
2. .NET 4.0;
3. Visual Studio 2010;
4. Windows Phone Developer Tools RTW;
5. Sqlite Client for Windows Phone (http://sqlitewindowsphone.codeplex.com/);
6. (推荐) sqlite-manager (http://code.google.com/p/sqlite-manager/);
7. (推荐) MVVM Light Toolkit (http://mvvmlight.codeplex.com/).
一、Sqlite Client for Windows Phone简介
大家都知道，SQLite是一个著名的开源的嵌入式的数据库系统，目前已经提供对于iOS和Android的良好支持。在此，应当让我们感谢Dan Ciprian Ardelean，是他带给我们WP7版本的SQLite-C#-SQLite!最近几个月，作者对早期的版本又进行了更新，得到一个功能更强大和更容易使用的解决方案，改名为Sqlite Client for Windows Phone，在知名的开源网站CodePlex上发布，网址是http://sqlitewindowsphone.codeplex.com/releases。
|
Sqlite Client for Windows Phone进行大范围的更新，如提供对于布尔类型、大型数据(Blobs)以及事务的全面支持，此外，下载包中还一并提供了一个全面的示例，供开发者学习之用。
|
接下来的操作就很简单了：重新构建源码工程，得到一个程序集Community.CsharpSqlite.WP.dll(Release版本大小是525 KB)。然后，在你的WP7 Silverlight 项目中添加对该程序集的引用。最后，你便可以使用Sqlite Client for Windows Phone提供的本地数据库支持功能了。
二、Sqlite Client for Windows Phone基础类库剖析
如果您以前有过任何基于SQL脚本的数据库编程经验，那么您可以轻松地使用Sqlite Client for Windows Phone功能。特别值得一提的是，此工程建基于以前的C#-SQLite项目之一，通过引入几个帮助器类(在文件SQLiteClient.cs)，即SQLiteException、SQLiteConnection和SQLiteCommand，进一步简化了基本的数据库和表相关操作。接下来的几幅图展示了Sqlite Client for Windows Phone中提供的主要组件及其之间的关联关系。
|
图4. SQLiteConnection类中的主要组件
图5. SQLiteCommand类中的主要组件
怎么样!如果您以前熟悉任何基于SQL的数据库开发，相信上面的这些组件对您会非常亲切吧。
先别急，在正式使用Sqlite Client for Windows Phone之前，有必要再向您介绍另外一个非常有用的工具，名为sqlite-manager (http://code.google.com/p/sqlite-manager/)。这个工具是以FireFox插件的方式提供的。到现在您应该明白了，绝大多数与SQLite数据库相关的操作，例如创建SQLite数据库、表、视图、索引等等，都可以通过sqlite-manager轻松完成。
1.使用SQLite Manager简化数据库管理
如前所述，SQLite Manager是一个Firefox插件，使用Firefox的加载项管理器你可以很容易地获取和安装这个控件(图6)。
|
如图所示，如果你打开Firefox的插件管理器，然后输入“SQLite Manager”搜索文本，你会很容易检索到此加载项。然后，您可以点击按钮“添加到Firefox... ”开始下载并安装SQLite Manager。请注意，在Firefox的提示后，你应该重新启动Firefox以完成安装。
使用SQLite Manager是容易的。说实在的，这是我第一次使用SQLite Manager，我发现这个工具功能强大而且极易上手。如果您使用过VB6中，你可能熟悉其中内置的数据库管理工具-VisData(以便以内置方式创建小型的Access数据库)。说实话，VisData确实是不容易使用，但在当时我们觉得已经相当不错了。现在，你只须记住，SQLite Manager的功能要比VisData强大1000倍。下图展示了SQLite Manager的一个使用快照。
|
从图中可见，你可以使用SQLite Manager来实现几种各种SQLite相关操作。请注意，要想了解更多的有关于SQLite的概念及详细使用语法，请从这款插件的帮助菜单中寻找答案。
另外，你也会注意到，在本文简单的示例工程中，我仅创建了一个表格Customer，对应的数据库文件为database1.sqlite(如图8所示)。
在创建完数据库database1.sqlite后，关闭SQLite Manager插件。然后，把此文件复制或移动到对应示例工程WP7SQLiteClient的根目录下。请注意，接下来，把它的Build Action属性设置为Resource模式。设置成这种模式的原因与接下来的操作方式相关。如果选择Content模式，则在后台的示例工程中你需要修改对应的部分源码。
2.一个有用的工具类-DBHelper
如上所述，Sqlite Client for Windows Phone使用众所周知的SQL操作针对典型的数据库操作提供了一个高层次的封装。因此，在Silverlight for Windows Phone 7编程中为了处理SQLite数据库操作，我们可以直接使用在文件SQLiteClient.cs中定义的对象(在源库项目)，即SQLiteException、SQLiteConnection和SQLiteCommand等。
虽然Sqlite Client for Windows Phone并没有提供与独立存储的直接互动，但显然增加对独立存储支持是必要的，这样可以改善系统的性能。因此，我们可以进一步封装前面提到的SQLiteClient对象。为此，Chris开发了一个非常好用的实用工具类，叫做DBHelper。为了应用于我们自己的示例，我对它做了轻微的修改。完整的源码如下。
列表1：更新版本的工具类DBHelper
//others omitted…
using SQLiteClient;
using System.Linq;
using System.IO.IsolatedStorage;
using System.Collections.Generic;
using System.Collections.ObjectModel;
namespace WP7SQLiteClient.Helpers
public class DBHelper
private String _dbName;
private SQLiteConnection db = null;
public DBHelper(String assemblyName, String dbName)
IsolatedStorageFile store =IsolatedStorageFile.GetUserStoreForApplication();
if (!store.FileExists(dbName))
CopyFromContentToStorage(assemblyName, dbName);
_dbName = dbName;
~DBHelper()
Close();
private void Open()
if (db == null)
db = new SQLiteConnection(_dbName);
private void Close()
if (db != null)
db.Dispose();
db = null;
//Insert operation
public int Insert(T obj, string statement) where T : new()
try
Open();
SQLiteCommand cmd = db.CreateCommand(statement);
int rec = cmd.ExecuteNonQuery(obj);
return rec;
catch (SQLiteException ex)
System.Diagnostics.Debug.WriteLine(Insert failed: + ex.Message);
throw ex;
// Delete operation
public void Delete(string statement) where T : new()
try
Open();
SQLiteCommand cmd = db.CreateCommand(statement);
cmd.ExecuteNonQuery();
catch (SQLiteException ex)
System.Diagnostics.Debug.WriteLine(Deletion failed: + ex.Message);
throw ex;
//Query operation
public List SelectList(String statement) where T : new()
Open();
SQLiteCommand cmd = db.CreateCommand(statement);
var lst = cmd.ExecuteQuery();
return lst.ToList();
public ObservableCollection SelectObservableCollection(String statement)
where T : new()
List lst = SelectList(statement);
ObservableCollection oc = new ObservableCollection();
foreach (T item in lst)
oc.Add(item);
return oc;
private void CopyFromContentToStorage(String assemblyName,String dbName)
IsolatedStorageFile store =
IsolatedStorageFile.GetUserStoreForApplication();
System.IO.Stream src =
Application.GetResourceStream(
new Uri(/ + assemblyName + ;component/ + dbName,
UriKind.Relative)).Stream;
IsolatedStorageFileStream dest =
new IsolatedStorageFileStream(dbName,
System.IO.FileAccess.Write, store);
src.Position = 0;
CopyStream(src, dest);
dest.Flush();
dest.Close();
src.Close();
dest.Dispose();
private static void CopyStream(System.IO.Stream input,
IsolatedStorageFileStream output)
byte[] buffer = new byte[32768];
long TempPos = input.Position;
int readCount;
do
readCount = input.Read(buffer, 0, buffer.Length);
if (readCount > 0)
output.Write(buffer, 0, readCount);
} while (readCount > 0);
input.Position = TempPos;
顺便说一句，对于上面这个帮助类我也没有提供细致的优化编码。希望读者根据您的相关工作能够继续进行这项工作(例如提供更好的泛型化的CRUD支持)并分享给广大网友。简言之，我主要是增加了插入和删除方法。上面的代码中最引起您注意是地方一定是方法CopyFromContentToStorage，正是借助这个方法我们实现了上述目标-建立起SQLite数据库与独立存储的关系。
三、小结
本文中简要介绍了Sqlite Client for Windows Phone的主要功能及相关的辅助开发工具。在接下来的第二篇文章中，我们将具体构建一个简单的Windows Phone 7客户端应用程序，当然要涉及到Sqlite Client for Windows Phone的基本编程技巧。
1：什么是桥接
在桥接模式中，不太好理解的就是桥接的概念。什么是桥接？为何需要桥接？如何桥接？把这些问题搞清楚了，也就基本明白桥接的含义了。
一个一个来，先看看什么是桥接？所谓桥接，通俗点说就是在不同的东西之间搭一个桥，让它们能够连接起来，可以相互通讯和使用。那么在桥接模式中到底是给什么东西来搭桥呢？就是为被分离了的抽象部分和实现部分来搭桥，比如前面示例中在抽象的消息和具体消息发送之间搭个桥。
但是这里要注意一个问题，在桥接模式中的桥接是单向的，也就是只能是抽象部分的对象去使用具体实现部分的对象，而不能反过来，也就是个单向桥。
2：为何需要桥接
为了达到让抽象部分和实现部分都可以独立变化的目的，在桥接模式中，是把抽象部分和实现部分分离开来的，虽然从程序结构上是分开了，但是在抽象部分实现的时候，还是需要使用具体的实现的，这可怎么办呢？抽象部分如何才能调用到具体实现部分的功能呢？很简单，搭个桥就可以了。搭个桥，让抽象部分通过这个桥就可以调用到实现部分的功能了，因此需要桥接。
3：如何桥接
这个理解上也很简单，只要让抽象部分拥有实现部分的接口对象，就桥接上了，在抽象部分即可通过这个接口来调用具体实现部分的功能。也就是说，桥接在程序上体现了在抽象部分拥有实现部分的接口对象，维护桥接就是维护这个关系。
4：独立变化
桥接模式的意图是使得抽象和实现可以独立变化，都可以分别扩充。也就是说抽象部分和实现部分是一种非常松散的关系。从某个角度来讲，抽象部分和实现部分是可以完全分开的，独立的，抽象部分不过是一个使用实现部分对外接口的程序罢了。
如果这么看桥接模式的话，就类似于策略模式了。抽象部分需要根据某个策略，来选择真实的实现，也就是说桥接模式的抽象部分相当于策略模式的上下文。更原始的就直接类似于面向接口编程，通过接口分离的两个部分而已。但是别忘了，桥接模式的抽象部分，是可以继续扩展和变化的，而策略模式只有上下文，是不存在所谓抽象部分的。
那抽象和实现为何还要组合在一起呢？原因是在抽象部分和实现部分还是存在内部联系的，抽象部分的实现通常是需要调用实现部分的功能来实现的。
5：动态变换功能
由于桥接模式中的抽象部分和实现部分是完全分离的，因此可以在运行时动态组合具体的真实实现，从而达到动态变换功能的目的。
从另外一个角度看，抽象部分和实现部分没有固定的绑定关系，因此同一个真实实现可以被不同的抽象对象使用；反过来，同一个抽象也可以有多个不同的实现。就像前面示例的那样，比如，站内短消息的实现功能，可以被普通消息、加急消息或是特急消息等不同的消息对象使用；反过来，某个消息具体的发送方式，可以是站内短消息，或者是E-mail，也可以是手机短消息等具体的发送方式。
6：退化的桥接模式
如果Implementor仅有一个实现，那么就没有必要创建Implementor接口了，这是一种桥接模式退化的情况。这个时候Abstraction和Implementor是一对一的关系，虽然如此，也还是要保持它们的分离状态，这样的话，它们才不会相互影响，才可以分别扩展。
也就是说，就算不要Implementor接口了，也要保持Abstraction和Implementor是分离的，模式的分离机制仍然是非常有用的。
7：桥接模式和继承
继承是扩展对象功能的一种常见手段，通常情况下，继承扩展的功能变化纬度都是一纬的，也就是变化的因素只有一类。
对于出现变化因素有两类的，也就是有两个变化纬度的情况，继承实现就会比较痛苦。比如上面的示例，就有两个变化纬度，一个是消息的类别，不同的消息类别处理不同；另外一个是消息的发送方式。
从理论上来说，如果用继承的方式来实现这种有两个变化纬度的情况，最后实际的实现类应该是两个纬度上可变数量的乘积那么多个。比如上面的示例，在消息类别的纬度上，目前的可变数量是3个，普通消息、加急消息和特急消息；在消息发送方式的纬度上，目前的可变数量也是3个，站内短消息、Email和手机短消息。这种情况下，如果要实现全的话，那么需要的实现类应该是：3 × 3 = 9个。
如果要在任何一个纬度上进行扩展，都需要实现另外一个纬度上的可变数量那么多个实现类，这也是为何会感觉扩展起来很困难。而且随着程序规模的加大，会越来越难以扩展和维护。
而桥接模式就是用来解决这种有两个变化纬度的情况下，如何灵活地扩展功能的一个很好的方案。其实，桥接模式主要是把继承改成了使用对象组合，从而把两个纬度分开，让每一个纬度单独去变化，最后通过对象组合的方式，把两个纬度组合起来，每一种组合的方式就相当于原来继承中的一种实现，这样就有效地减少了实际实现的类的个数。
从理论上来说，如果用桥接模式的方式来实现这种有两个变化纬度的情况，最后实际的实现类应该是两个纬度上可变数量的和那么多个。同样是上面那个示例，使用桥接模式来实现，实现全的话，最后需要的实现类的数目应该是：3 + 3 = 6个。
这也从侧面体现了，使用对象组合的方式比继承要来得更灵活。
8：桥接模式的调用顺序示意图
桥接模式的调用顺序如图24.8所示。
 |
| （点击查看大图）图24.8 桥接模式的调用顺序示意图 |
看到“门面”这个词，大家一定都觉得很熟悉。不错，这个词正是借用了我们日常生活中的“门面”的概念。日常生活中的“门面”，正是我们买东西的地方。因此可以这么说，“门面”就是这么一个地方，它们跟各种商品的生产商打交道，收集商品后，再卖给我们。换句话说，如果没有“门面”，我们将不得不直接跟各种各样的生产商买商品；而有了“门面”，我们要买东西，直接跟“门面”打交道就可以了。
Facade模式正是这样一个“门面”：我们本来需要与后台的多个类或者接口打交道，而Facade模式是客户端和后台之间插入一个中间层——门面，这个门面跟后台的多个类或接口打交道，而客户端只需要跟门面打交道即可。
使用Facade模式可以说是后台设计和编码人员的一个必备素质。我不止碰到过一个这样的后台开发人员，他们认为只要把后台功能完成了就万事大吉，而没有站在后台使用者的角度来看一看自己写出来的代码。其实，我们写出来的后台代码是要给别人使用的，所以我们提供给使用者的接口要越简单越好，这不单是对使用者好，同时对开发者也是好处多多的，至少你的接口简单了，你和使用者的交流就容易了。
而Facade模式中的Facade类正是这样一个用户接口，它和后台中的多个类产生依赖关系，而后台的客户类则只跟Facade类产生依赖关系。为什么要这么做？其中的原因十分简单：后台的开发者熟悉他自己开发的各个类，也就容易解决和多个类的依赖关系，而后台的使用者则不太熟悉后台的各个类，不容易处理和它们之间的依赖；因此，后台的开发者自己在Facade类中解决了与后台多个类之间的依赖，后台的使用者只需要处理和Facade类的依赖即可。
好了，闲话少说。我们下面就以几个具体的例子来看一看Facade模式是怎么使用的。实际编程中，能使用到Facade模式的情况有很多，以下就分两种情况来具体说一说Facade模式的使用。可能还会有其他的情况，大家在实践中也可以加以补充。
第一种情况，客户类要使用的功能分布在多个类中，这些类可能相互之间没有什么关系；客户在使用后台的时候，必须先初始化要使用到的功能所在的类，然后才能使用。这时候，适合将这些功能集中在一个Facade类里，还可以替用户做一些初始化的工作，以减轻用户的负担。
例如，以商店为例。假如商店里出售三种商品：衣服、电脑和手机。这三种商品都是由各自的生产厂商卖出的，如下：
public class CoatFactory
{
public Coat saleCoat()
{
……
return coat;
}
……
}
然后是电脑的厂家类：
public class ComputerFactory
{
public Computer saleComputer()
{
……
return computer;
}
……
}
最后是手机商类：
public class MobileFactory
{
public Mobile saleMobile()
{
……
return mobile;
}
……
}
如果没有商店，我们就不得不分别跟各自的生产商打交道，如下：
//买衣服
CoatFactory coatFactory = new CoatFactory();
coatFactory.saleCoat();
//买电脑
ComputerFactory computerFactory = new ComputerFactory();
computerFactory.saleComputer();
//买手机
MobileFactory mobileFactory = new MobileFactory();
mobileFactory.saleMobile();
对我们顾客来说，和这么多的厂家类打交道，这显然是够麻烦的。
这样，我们就需要创建一个商店类了，让商店类和这些厂家打交道，我们只和商店类打交道即可，如下：
public class Store
{
public Coat saleCoat()
{
CoatFactory coatFactory = new CoatFactory();
return coatFactory.saleCoat();
}
public Computer saleComputer()
{
ComputerFactory computerFactory = new ComputerFactory();
return computerFactory.saleComputer();
}
public Mobile saleMobile()
{
MobileFactory mobileFactory = new MobileFactory();
return mobileFactory.saleMobile();
}
}
好了，现在我们要买东西，不用去跟那么多的厂家类打交道了。
Store store =new Store();
//买衣服
store.saleCoat();
//买电脑
store.saleComputer();
//买手机
store.saleMobile();
呵呵，这样对我们客户类来说，是不是简单多了。
第二种情况客户要完成的某个功能，可能需要调用后台的多个类才能实现，这时候特别要使用Facade模式。不然，会给客户的调用带来很大的麻烦。请看下面的例子。
我经常看到后台编码人员，强迫它们的使用者写出如下的代码：
……
String xmlString = null;
int result = 0;
try
{
xmlString = gdSizeChart.buildDataXML(incBean);
String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f));
out.print(xmlString);
out.close();
System.out.println("\r\n\r\n sumaryAction" + xmlString + "\r\n\r\n");
request.setAttribute("xmlString", xmlString);
}
catch(Exception ex)
{
ex.printStackTrace();
}
这段代码前面即省略号省略掉的一部分是客户类调用后台的一部分代码，是一个相对独立的功能。后面这一部分也是一个相对独立的功能，而后台代码设计人员却把这个功能留给客户类自己来实现。
我就很怀疑，让客户类做这么多事情，到底要你的后台做什么？你还不如直接把所有的事情都给客户类做了得了。因为，你后台做了一半，剩下的一部分给客户类做，客户类根本就不明白怎么回事，或者说他不清楚你的思路，这样做下去更加困难。可能这点逻辑对你来说，很简单。但使用者不明白你的思路啊，他不知道来龙去脉，怎么往下写？
如果在这里有一个Facade类，让它来做不该由客户类来做的事，是不是简单多了呢？如下是一个Facade类：
public class Facade
{
public static void doAll(PE_MeasTableExdBean incBean, HttpServletRequest request)
{
……
request.setAttribute(“xmlString”,Facade.getFromOut(incBean));
}
private static String getFromOut(PE_MeasTableExdBean incBean)
{
try
{
xmlString = gdSizeChart.buildDataXML(incBean);
String path = "D:/Eclipse3.0/workspace/PLMSuite/AppWeb/PM/productSpecification/gridfile.xml";
File f = new File(path);
PrintWriter out = new PrintWriter(new FileWriter(f));
out.print(xmlString);
out.close();
System.out.println("\r\n\r\n sumaryAction" + xmlString + "\r\n\r\n");
return xmlString;
}
catch(Exception ex)
{
ex.printStackTrace();
return null;
}
}
}
那么客户类的调用就是下面的样子：
Facade.doAll(incBean,request);
这样，客户是不是轻松多了？值得注意的是，Facade类中的getFromOut方法其实不应该在Facade类中，本文为了简单起见而放在了这个类中，对Facade类来说是不符合单一职责原则的。
最后总结一下第二种情况的模式。后台为实现某一个功能有如下类：
public class ClassA
{
public void doA()
{
……
}
……
}
public class ClassB
{
public void doB()
{
……
}
……
}
public class ClassC
{
public void doC()
{
……
}
……
}
如果客户类需要这样调用：
……
ClassA a = new ClassA();
a.doA();
ClassB b = new ClassB();
b.doB();
ClassC c = new ClassC();
c.doC();
……
那么就适合做一个Facade类，来替客户类来完成上述的功能，如下：
public class Facade
{
public void doAll()
{
ClassA a = new ClassA();
a.doA();
ClassB b = new ClassB();
b.doB();
ClassC c = new ClassC();
c.doC();
}
}
则客户类的调用如下：
……
Facade Facade = new Facade();
Facade.doAll();
……