这里的事务日志清理是指截断事务日志并释放空间。

操作方法：

1、通过备份事务日志进行截断

备份时的默认选项就是Truncate the transaction log（截断事务日志），备份完成后，事务日志就会自动被截断，但这时你查看日志文件的大小还是和原来一样。所以，需要通过第二步释放日志文件占用的空间。

2、通过收缩日志文件释放日志文件占用的空间

• 将恢复模式由完整（Full）改为简单（Simple）
• 收缩（Shrink）日志文件
• 将恢复模式由简单（Simple）改为完整（Full）

3、收缩数据库（Shrink database）

观察360的短信拦截和QQ管家的短信拦截，发现先安装的就能先拦截到的短信，然后中断广播，之后谁都不能获取到短信。从这里可以推出系统大概有一个广播表，同等级的按安装先后顺序排放。目前的方法是在应用层调用framework API进行控制的。

为了能更好的了解Android接收短信的流程，我进行了更深入的分析，从RIL的通信架构来分析当接收到短信的整个流程。从frameword里的RIL.java

文件可以看出发送短信和接收短信是通过Receiver和Sender架构，发送短信主要通过Sender框架，主要如下(图是从网上窃滴~)：

上层函数调用Command Interface将请求消息发送到sender架构，由该架构将请求发送到RILD的架构。

目前主要分析接收短信走过的那些渠道，因此发送短信只是略微的说明一下。

接收短信流程如下（从发送消息到接收消息的处理流程）(图是从网上剽滴~)：

从 上图右边那块（结合代码）可以看出短信接收是从ril.cpp文件通过socket与RIL.java的socket交流，当ril.cpp收到短信后处 理完成后会通过socket发送字节流给上层的RIL.java，而在RIL.java中有Receiver架构（该架构主要是一条线程）在不断监听，

Receiver架构代码：

class RILReceiver implements Runnable {

byte[] buffer;

RILReceiver() {

buffer = new byte[RIL_MAX_COMMAND_BYTES];

}

public void

run() {

int retryCount = 0;

try {
for (;;) {

LocalSocket s = null;

LocalSocketAddress l;

try {

s = new LocalSocket();

l = new LocalSocketAddress(SOCKET_NAME_RIL,

LocalSocketAddress.Namespace.RESERVED);

s.connect(l);

} catch (IOException ex) {

try {

if (s != null) {

s.close();

}

} catch (IOException ex2) {

// ignore failure to close after failure to connect

}

// don’t print an error message after the the first time

// or after the 8th time

if (retryCount == 8) {

Log.e(LOG_TAG,

“Couldn’t find ‘” + SOCKET_NAME_RIL

+ “‘ socket after ” + retryCount

+ ” times, continuing to retry silently”);

} else if (retryCount > 0 && retryCount < 8) {

Log.i(LOG_TAG,

“Couldn’t find ‘” + SOCKET_NAME_RIL

+ “‘ socket; retrying after timeout”);

}

try {

Thread.sleep(SOCKET_OPEN_RETRY_MILLIS);

} catch (InterruptedException er) {

}

retryCount++;

continue;

}

retryCount = 0;

mSocket = s;

Log.i(LOG_TAG, “Connected to ‘” + SOCKET_NAME_RIL
+ “‘ socket”);

int length = 0;

try {

InputStream is = mSocket.getInputStream();

for (;;) {

Parcel p;

length = readRilMessage(is, buffer);

if (length < 0) {

// End-of-stream reached

break;

}

p = Parcel.obtain();

p.unmarshall(buffer, 0, length);

p.setDataPosition(0);

// Log.v(LOG_TAG, “Read packet: ” + length +
// ” bytes”);

processResponse(p);

p.recycle();

}

} catch (java.io.IOException ex) {

Log.i(LOG_TAG, “‘” + SOCKET_NAME_RIL
+ “‘ socket closed”,

ex);

} catch (Throwable tr) {

Log.e(LOG_TAG, “Uncaught exception read length=”
+ length +

“Exception:” + tr.toString());

}

Log.i(LOG_TAG, “Disconnected from ‘” + SOCKET_NAME_RIL

+ “‘ socket”);

setRadioState(RadioState.RADIO_UNAVAILABLE);

try {

mSocket.close();

} catch (IOException ex) {

}

mSocket = null;

RILRequest.resetSerial();

// Clear request list on close

synchronized (mRequestsList) {

for (int i = 0, sz = mRequestsList.size(); i < sz; i++) {

RILRequest rr = mRequestsList.get(i);

rr.onError(RADIO_NOT_AVAILABLE, null);

rr.release();

}

mRequestsList.clear();

}

}
} catch (Throwable tr) {

Log.e(LOG_TAG, “Uncaught exception”, tr);

}

}

}

因 此从代码可以看出获取到短信消息后经过一系列地分析然后提交给processResponse(p); 方法处理，处理过程中会有两种response，一种是主动上报，比如网络状态，短信，来电等都不需要经过请求，用unsolicited词语专门描述， 另一种才是真正意义上的response，也就是命令的响应用solicited描述。那接收短信就是属于unsolicited，跳到 processUnsolicited (Parcel p)方法，查看该方法可得出会继续触发以下方法mSMSRegistrant.notifyRegistrant(new AsyncResult(null, sms, null)); 追溯该方法对象的创建，最后发现该方法设置handler的源头是在：SMSDispatcher类里

该 类做了一件重要的事：给Command Interface设置handler的处理方法，就是当接收到短信后触发mSMSRegistrant.notifyRegistrant(new AsyncResult(null, sms, null));方法，然后回调调用之前传入的handler，接着在handler里面处理短信消息。

mCm.setOnNewSMS(this, EVENT_NEW_SMS, null);

mCm.setOnSmsStatus(this, EVENT_NEW_SMS_STATUS_REPORT, null);

mCm.setOnIccSmsFull(this, EVENT_ICC_FULL, null);

mCm.registerForOn(this, EVENT_RADIO_ON, null);

handler处理接收到的短信消息：

@Override
public void handleMessage(Message msg) {

AsyncResult ar;

switch (msg.what) {

case EVENT_NEW_SMS:

// A new SMS has been received by the device

if (Config.LOGD) {

Log.d(TAG, “New SMS Message Received”);

}

SmsMessage sms;

ar = (AsyncResult) msg.obj;

if (ar.exception != null) {

Log.e(TAG, “Exception processing incoming SMS. Exception:”
+ ar.exception);

return;

}

sms = (SmsMessage) ar.result;

try {

int result = dispatchMessage(sms.mWrappedSmsMessage);

if (result != Activity.RESULT_OK) {

// RESULT_OK means that message was broadcast for app(s) to
// handle.

// Any other result, we should ack here.

boolean handled = (result == Intents.RESULT_SMS_HANDLED);

notifyAndAcknowledgeLastIncomingSms(handled, result, null);

}

} catch (RuntimeException ex) {

Log.e(TAG, “Exception dispatching message”, ex);

notifyAndAcknowledgeLastIncomingSms(false,
Intents.RESULT_SMS_GENERIC_ERROR, null);

}

break;

}

}

int result = dispatchMessage(sms.mWrappedSmsMessage); 该段会通过子类（GsmSMSDispatcher）的dispatchMessage方法处理。经一系列的判断处理最后普通短信将交给 dispatchPdus(pdus);这个方法处理。

protected void dispatchPdus(byte[][] pdus) {

Intent intent = new Intent(Intents.SMS_RECEIVED_ACTION);

intent.putExtra(“pdus”, pdus);

dispatch(intent, “Android.permission.RECEIVE_SMS”);

}

void dispatch(Intent intent, String permission) {

// Hold a wake lock for WAKE_LOCK_TIMEOUT seconds, enough to give any

// receivers time to take their own wake locks.

mWakeLock.acquire(WAKE_LOCK_TIMEOUT);

mContext.sendOrderedBroadcast(intent, permission, mResultReceiver,

this, Activity.RESULT_OK, null, null);

}

最 后，我们可以看出这个方法将短信通过顺序广播播放出去（action是SMS_RECEIVED_ACTION），无论广播是否被中断最后都会调用 mResultReceiver，这里会将已读或未读的状态告诉给对方。如果短信广播中间没有受到終止，那么接下来的流程 是：PrivilegedSmsReceiver类接收到Android.provider.Telephony.SMS_RECEIVED的请求然后调 用 intent.setClass(context, SmsReceiverService.class); 启动SmsReceiverService服务类来处理短信并保存短信。

参考文章：

http://newfaction.net/2011/03/15/android-2-2-ril-java-part-of-the-code-profile.html

http://blog.csdn.net/maxleng/article/details/5593759

http://www.360doc.com/content/10/0625/11/496343_35127382.shtml

示例源码

这 两天学习了一下MVVM模式,和大家分享一下,也作为自己的学习笔记.这里不定义MVVM的概念,不用苍白的文字说它的好处,而是从简单的赋值讲起,一步 步建立一个MVVM模式的Simple.通过前后对比留给读者自己去思考.我也不知道理解是否正确,有不对的地方,希望指出.

赋值VS绑定

要理解MVVM模式,最重要的是理解绑定的概念.做B/S或者对C/S理解不够的程序员可能不了解”绑定”,它与赋值类似,但又”高级”一点.

一个简单的类:

public class MyClass
{           
    public MyClass() {
        this._Time = DateTime.Now.ToString();
    }     

    private string _Time;
    public string Time {
        get {
            return this._Time;
        }
        set {
            this._Time = value;
        }
    }
}

赋值

private void UpdateTime_Click(object sender, RoutedEventArgs e) {
    _MyClass.Time = DateTime.Now.ToString();
    this.lable1.Content = _MyClass.Time;
}

private void Grid_Loaded(object sender, RoutedEventArgs e) {
    this.lable1.Content = _MyClass.Time;
}

很简单的对lable1的Content属性的赋值.总结一下这种模式的流程图:

这种模式很简单,很容易理解.缺点也是很明显,View跟CodeBehind紧紧耦合在一起了(事件方法里面需要知道lable1),还有到处都是this.lable1.Content = _MyClass.Time; 这样的赋值代码,这样可维护性是很低的.于是就有了绑定.

属性绑定

绑定就是把把东西关联在一起,例如人的手脚是和整个身体绑定在一起的,手指受伤了,人会感到疼痛.属性绑定通常是把一个Model属性绑定给一个控件的属性,于是它们就有了联系,Model的属性变化了,控件的属性也会变化.

wpf的绑定.

首先把View的DataContext设为MyClass.

<Window.DataContext>
    <local:MyClass />
</Window.DataContext>

这样我们就可以把MyClass的属性绑定给lable1的Content.

<Label Grid.Column="1" Grid.Row="1" Content="{Binding Time}" />

WinForm也能绑定:

public Form1() {
    InitializeComponent();
    this.label2.DataBindings.Add("Text", _MyClass, "Time", true);
}

运行程序:

点击Update Time按钮,比较遗憾,绑定那一行的时间并没有更新.看来需要做更多的工作.(见源码Example1)

INotifyPropertyChanged接口

原来对于上面的那个poco类,它的属性Time发生变化时,紧紧靠<Label Grid.Column=”1″ Grid.Row=”1″ Content=”{Binding Time}” />或者this.label2.DataBindings.Add(“Text”, _MyClass, “Time”, true); 是不够的,lable不能”智能”地知道MyClass的Time变化了,需要MyClass主动去通知lable:我的Time属性变化 了.INotifyPropertyChanged接口就是这样的功能.

INotifyPropertyChanged的源码:

// 摘要:向客户端发出某一属性值已更改的通知。
public interface INotifyPropertyChanged
{
    // 摘要:在更改属性值时发生。
    event PropertyChangedEventHandler PropertyChanged;
}

PropertyChangedEventHandler里的事件参数源码:

// 摘要:为 System.ComponentModel.INotifyPropertyChanged.PropertyChanged 事件提供数据。
 public class PropertyChangedEventArgs : EventArgs
 {
     // 摘要:初始化 System.ComponentModel.PropertyChangedEventArgs 类的新实例。
     // 参数:propertyName:已更改的属性名
     [TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
     public PropertyChangedEventArgs(string propertyName);

     // 摘要:获取已更改的属性名。
     // 返回结果:已更改的属性名。
     public virtual string PropertyName { get; }
 }

接口非常简单,就一个PropertyChanged事件,而事件委托的参数也很简单,一个字符串属性名.Model继承 INotifyPropertyChanged后,在这个事件中是通知者的角色(执行事件),而<Label Grid.Column=”1″ Grid.Row=”1″ Content=”{Binding Time}” />和this.label2.DataBindings.Add(“Text”, _MyClass, “Time”, true); 这里可以理解为事件的订阅.

继承INotifyPropertyChanged后的MyClass:

public class MyClass : INotifyPropertyChanged
{
    public MyClass() {
        this._Time = DateTime.Now.ToString();
    }

    private string _Time;
    public string Time {
        get {
            return this._Time;
        }
        set {
            if (this._Time != value) {
                this._Time = value;
                if (PropertyChanged != null) {
                    PropertyChanged(this, new PropertyChangedEventArgs("Time"));
                }
            }
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

重点是Set值时执行事件,运行程序发现,lable终于知道MyClass的属性变化了,它们绑定了.而且可以发现绑定是双向的,即控件的值更新,model的属性值也会更新,添加一个按钮显示model的属性值:

private void Show_Click(object sender, RoutedEventArgs e) {
    MessageBox.Show(_MyClass.Time);
}

这里做到了把Model的属性绑定给View的控件的属性中,下面看看集合的绑定.

集合绑定

跟上面一样,普通的集合控件们是不认的,要用特殊的集合,它就是ObservableCollection<T>,它继承了INotifyCollectionChanged和INotifyPropertyChanged.部分源码:

 [Serializable]
 public class ObservableCollection<T> : Collection<T>, INotifyCollectionChanged, INotifyPropertyChanged
一个简单的类:

public class Employe
{
    public ObservableCollection<string> Employees { get; set; }

    public Employe() {
        Employees = new ObservableCollection<string>() 
        {
            "肥猫", "大牛", "猪头"
        };
    }
}

把它绑定到一个ComboBox中:

<ComboBox Grid.Column="2" Grid.Row="0"  ItemsSource="{Binding Employees}" Width="50px"/>

另外做一个按钮添加来Employees

private void AddDepartment_Click(object sender, RoutedEventArgs e) {
    _MyClass.Employees.Add(this.textBox1.Text);
}

运行程序,添加一个Employee,发现ComboBox也更新了(见源码Example3).

命令绑定

还有一个绑定就是命令绑定.实际解决的是要把View完全解耦,不用再写控件事件,因为AddDepartment_Click这样的写法就会把View和CodeBehind的耦合在一起,跟上面属性赋值类似.

ICommand

// 摘要:定义一个命令
[TypeConverter("System.Windows.Input.CommandConverter, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null")]
[ValueSerializer("System.Windows.Input.CommandValueSerializer, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null")]
public interface ICommand
{
    // 摘要: 当出现影响是否应执行该命令的更改时发生。
    event EventHandler CanExecuteChanged;

    // 摘要:定义用于确定此命令是否可以在其当前状态下执行的方法。    
    // 参数:parameter:此命令使用的数据。如果此命令不需要传递数据，则该对象可以设置为null。
    // 返回结果:如果可以执行此命令，则为true；否则为false。
    bool CanExecute(object parameter);
    //
    // 摘要:定义在调用此命令时调用的方法。
    // 参数:parameter:此命令使用的数据。如果此命令不需要传递数据，则该对象可以设置为 null。
    void Execute(object parameter);
}

最主要需要实现的是Execute方法.即事件发生时要执行的方法.下面把Add Department的按钮事件去掉,改为绑定一个命令.实现这个命令首先要得到的是textbox上的值.要在命令里得到View控件的值,可以在 model里新建一个属性值与这个控件绑定,因为绑定是双向的,所以属性值就是控件的值.根据上面的Employe类添加如下代码:

private string _NewEmployee;
public string NewEmployee {
    get {
        return this._NewEmployee;
    }
    set {
        if (this._NewEmployee != value) {
            this._NewEmployee = value;
            if (PropertyChanged != null)
                PropertyChanged(this, new PropertyChangedEventArgs("NewEmployee"));
        }
    }
}

每个命令要实现为一个单独的类,继承ICommand,这里用一个委托把添加部门的逻辑转移到Employe中:

public class AddEmployeeCommand : ICommand
{
    Action<object> _Execute;
    public AddEmployeeCommand(Action<object> execute) {
        _Execute = execute;
    }

    public bool CanExecute(object parameter) {
        return true;
    }

    public event EventHandler CanExecuteChanged {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }

    public void Execute(object parameter) {
        _Execute(parameter);
    }
}

Employe类再添加一个ICommand用作绑定:

private ICommand _AddEmployee;
public ICommand AddEmployee {
    get {
        if (_AddEmployee == null) {
            _AddEmployee = new AddEmployeeCommand((p) =>
            {
                Employees.Add(NewEmployee);
            });
        }
        return _AddEmployee;
    }
}
有了AddEmployee 我们就可以绑定到按钮中:

<Button Grid.Column="0" Grid.Row="0" Content="Add Department" Command="{Binding AddEmployee}" />

到这里,我们可以得到跟上面一样的功能,但成功把按钮事件改为了命令绑定.(见源码Example4)

完成上面所有工作,我们解决了一个问题,即View”后面”的模块(Code Behind也好,Model也好)完全没了view的影子,”后面”的模块不用管textbox还是Label来显示一个Name,只管把Name赋值 就好了,也不用关心一个button还是一个picturebutton来点击,只管实现逻辑.但细心观察,代码还是有不少问题.

其中最主要的是为了实现上面的功能,污染了Employe这个类.Employe应该是常见的Model层中的一个类,它应该是一个poco类,职 责是定义领域模型和模型的领域(业务)逻辑.为了实现绑定,添加了各种接口和与领域(业务)无关的属性,这就是对Model的污染.所以,当想实现绑定, 而又不想污染model,就得引入新的一层–ViewModel,这样就走向了MVVM模式.

MVVM模式

VM是MVVM的核心.主要作用有两个.

1.提供属性和命令供View绑定

2.还要承担MVC模式中C(Controller)的职责,作为View和业务层的中间人.

模式实践.

把上面的代码稍为修改即可以改为MVVM模式.

Model,Employee回归Poco:

public class Employee
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }

    public void Add() {
        DataBase.AllEmployees.Add(this);
    }
}

ViewModel提供绑定的属性和命令:

public class EmployeeViewModel : INotifyPropertyChanged
   {
       public event PropertyChangedEventHandler PropertyChanged;

       /// <summary>
       /// 供?ComboBox绑ó定¨
       /// </summary>
       public ObservableCollection<Employee> Employees { get; set; }

       public EmployeeViewModel() {
           Employees = new ObservableCollection<Employee>(DataBase.AllEmployees);
       }

       #region 供?textbox 绑ó定¨        
       private string _NewEmployeeName;
       public string NewEmployeeName {
           get {
               return this._NewEmployeeName;
           }
           set {
               if (this._NewEmployeeName != value) {
                   this._NewEmployeeName = value;
                   if (this.PropertyChanged != null) {
                       PropertyChanged(this, new PropertyChangedEventArgs("NewEmployeeName"));
                   }
               }
           }
       }

       private string _NewEmployeeEmail;
       public string NewEmployeeEmail {
           get {
               return this._NewEmployeeEmail;
           }
           set {
               if (this._NewEmployeeEmail != value) {
                   this._NewEmployeeEmail = value;
                   if (this.PropertyChanged != null) {
                       PropertyChanged(this, new PropertyChangedEventArgs("NewEmployeeEmail"));
                   }
               }
           }
       }

       private string _NewEmployeePhone;
       public string NewEmployeePhone {
           get {
               return this._NewEmployeePhone;
           }
           set {
               if (this._NewEmployeePhone != value) {
                   this._NewEmployeePhone = value;
                   if (this.PropertyChanged != null) {
                       PropertyChanged(this, new PropertyChangedEventArgs("NewEmployeePhone"));
                   }
               }
           }
       }
       #endregion

       public ICommand AddEmployee {
           get {
               return new RelayCommand(new Action(() =>
                           {
                               if (string.IsNullOrEmpty(NewEmployeeName)) {
                                   MessageBox.Show("姓名不能为空!");
                                   return;
                               }
                               var newEmployee = new Employee { Name = _NewEmployeeName, Email = _NewEmployeeEmail, Phone = _NewEmployeePhone };
                               newEmployee.Add();
                               Employees.Add(newEmployee);
                           }));
           }
       }
   }

代码的职责非常明确,提供5个属性(1个命令,4个普通属性)供View绑定.虽然简单,但却产生了一大堆代码,可能这就是MVVM框架出现的原因.不管怎样,一个简单的MVVM模式的Simple就完成了(参考代码Example5).

MVVM:

参考:链接

昨天开始，博客园Web服务器出现CPU占用率很高的问题（平均在80%）以上，当前站点的IIS同时连接在15000上下波动，访问速度变慢。

CPU占用高，还带来一个副作用：当CPU占用超过90%时，IIS会自动停用“动态内容压缩”（dynamic content compress），造成带宽占用高。

高CPU、高带宽、低访问速度，“两高一低”造成园友的“抱怨”、服务员的“崩溃”。。。就像一阵风暴突袭一个美丽宁静的花园。。。

在服务员们的努力下，今天终于让园子恢复了平静，而解决方法是借助另外一个花园 —— Web Gardens。

具体操作是：在IIS的应用程序池设置中，将Maximum Worker Processes设置为4（原先为1），也就是由4个独立的进程运行当前站点。

用了Web Gardens之后，立杆见影，CPU占用立即降下来，IIS同时连接也随之下降，访问速度即刻恢复。

连续忙了好几个月，好久没有写东西了，最近稍微有点空，空闲的时候回到了对ASP.NET MVC RC（以下简称MVC RC）的研究上来。MVC RC的“脚手架（Scaffold）”功能可以说为MVC RC的开发如虎添翼，不过应用到真实的开发环境中似乎存在一些遗憾的地方：很多时候我们并不希望把Models、Views和Controllers放在同一个项目里面，而是把它们分离到不同的项目，然后由一个项目（比如Views）统一引用其他所有的项目程序集。但是这样做了以后，Controllers项目中脚手架的功能就“消失了”。

在Web（MVC RC）项目中，我们可以这样在Web项目中使用脚手架创建View页面：

或者创建Controller文件：

甚至可以在Controller文件中自动创建或者查看对应Action的View页面：

不过这一切经历了Views和Controllers的“生死离别”之后，就再也无法在Controllers中使用了（原因会在下文中说明）。下面我们来做一个测试。

首先我们先把M、V、C三层分离，比如这样：

需要注意的是当这样做的时候，在Controllers项目中需要引用以下这三个核心的程序集：

System.Web.Abstractions.dll

System.Web.Mvc.dll

System.Web.Routing.dll

以及一些在默认的Controller.cs文件中被引用到的命名空间，如：

System.Web

System.Configuration

以下是分离M-V-C（M之所以也要分离出去是因为C需要引用M，而C不能引用V）之后，运行的默认界面，说明这样的分离是成功的：

OK，到此为止MVC工作正常，只不过……无法在MyMvc.Controllers中使用MVC的脚手架：

分析一下原因：我们在把Controller分离出来的时候是建了“类库（Class Library）”，一个普通的类库当然无法使用MVC（Web）的脚手架，于是我打开了MyMvc.Web的项目文件MyMvc.Web.csproj，用记事本打开这个文件（本质上是一个XML文件），发现了一个和其他项目与众不同的地方：

<ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>

这个节点中用分号分割了3段看似Guid的代码，分别是：

{603c0e0b-db56-11dc-be95-000d561079b0}

{349c5851-65df-11da-9384-00065b846f21}

{fae04ec0-301f-11d3-bf4b-00c04f79efbc}

立刻对比了一下MyMvc.Controllers下面的MyMvc.Controllers. csproj，发现没有这个节点。喜出望外！于是马上将这个节点复制到MyMvc.Controllers. csproj对应的地方，重新加载项目以后，发现MyMvc.Controllers的脚手架功能回来了！

不过通过这样简单的添加还是发现了一些小小的瑕疵：细观MyMvc.Controller的项目图标类型，怎么和Web的时一样的(下图)？不爽。

看来这样的直接复制是把整个MVC Web Application下面的类型都一起复制过来了，为了避免日后不必要的麻烦，还是需要让Controllers变回“类库”，于是打起了那三个Guid的注意，经过两次两两搭配后（{fae04ec0-301f-11d3-bf4b-00c04f79efbc}一定要保留）发现，只要删除中间的{349c5851-65df-11da-9384-00065b846f21}之后，MyMvc.Controllers项目又回到了“类库”的状态：

于是猜测{fae04ec0-301f-11d3-bf4b-00c04f79efbc}对应了Web Application的项目类型，而{603c0e0b-db56-11dc-be95-000d561079b0}对应了MVC RC的模板。

注意：{603c0e0b-db56-11dc-be95-000d561079b0}对应了MVC RC(v1.0)的项目代码，

如果您使用的是MVC 2.0（包括Preview版本在内），对应的编码为：{F85E285D-A4E0-4152-9332-AB1D724D3325} ！

如果您使用的是MVC 3.0（包括Beta和RC版本在内），对应的编码为：{E53F8FEA-EAE0-44A6-8774-FFD645390401} ！

通过以上这些操作，分离了M-V-C结构，并且在Controllers中“完整”保留了MVC RC的脚手架的功能。

上面的“完整”之所以要突出一下，是因为这种保留实在是太“完整”了，以至于在Controller中自动添加View页面会添加到Controller项目中，而不是我们所希望的MyMvc.View项目中（查看对应View页面也存在相同的问题）。这倒是个大问题，如果这个问题不解决，那么“脚手架”反而成了“绊脚石”，这个问题如何解决呢？

请看下一篇《为ASP.NET MVC RC分离C-V项目后添加“脚手架”功能（二）》

（本文的实例也在《ASP.NET MVC RC分离C-V项目后添加“脚手架”功能（二）》中提供下载。）

作为一种以HTTP协议为基础的WCF 服务，只要客户端能模拟进行HTTP请求，都能成为服务的消费者。之前写过《对Jquery+JSON+WebService的一点认识》，觉得在REST是基于HTTP协议的，AJAX的操作也应该一样。但是事实上还是有些差别的。由于网上资源聊聊无几，因此记录下自己的个人体会。希望对你有些帮助！
本篇主要讲述的类容为在ASP.NET中，如何通过AJAX来消费REST服务。
使用JQuery框架模拟AJAX请求时，操作类型主要有GET、POST两种。本节也以这两种常用的方式来进行介绍。（type (String) : (默认: “GET”) 请求方式 (“POST” 或 “GET”)， 默认为 “GET”。注意：其它 HTTP 请求方法，如 PUT 和 DELETE 也可以使用，但仅部分浏览器支持。摘自：JQuery 1.4 API手册）。

• 本篇主要涉及的操作如下：

• 1、GET请求
• 2、POST请求，简单数据类型
• 3、POST请求，复杂数据类型

Jq+JSON消费REST WCF4.0 服务时，对返回给客户端数据格式，以及客户端传递给服务端数据格式是通过ResponseFormat、RequestFormat 两个枚举类型的指定的。如下代码所示。

服务端实现代码：

客户端实现代码
1、GET请求。

效果如下图：

2、POST请求，简单数据类型。

运行结果如下图：

3、POST请求，复杂数据类型
POST复杂数据类型与简单类型原理是一样的。在Web页面建构JSON数据对象，然后将其转换为JSON的字符串格式。
代码如下：

运行结果如下图：

如同在WebService中一样：客户端上传的JSON字符串格式的数据，会在服务端复杂数据类型中的相应字段中。
这样就通过JQ+JSON完成了与REST WCF的交互。但是有一点需要注意的是：在使用POST操作时，在客户端与服务端交互过程中，需要指定WebMessageBodyStyle、在GET操作时，不论格式，可以不必指定。用途是：指定是否包装参数和返回值。也就是在客户端与服务端的交互过程中，上传给服务端的参数以及服务端回传给客户端的返回值需要做怎样的包装操作。这一点非常重要，否则调用在消费服务是会有异常。
WebMessageBodyStyle的定义如下：

MSDN给出的说明如下：

• Bare 不包装请求和响应。
• Wrapped 包装请求和响应。
• WrappedRequest 包装请求，但不包装响应。
• WrappedResponse 包装响应，但不包装请求。

与WebService调用异同总结：

• 1、调用方式一样。
• 2、客户端发送给服务端数据格式略有差别。在WebService中可以通过形如：data: "{'name':'zhangsan'}",向服务端发送请求，但是这种字符串格式中RESTful中是不被支持的。
• 3、WebService调用结果通过.d获取，即json.d。而在RESTful Service中，直接获取,即json。
• 4、WebService不用指定客户端请求、服务端相应的格式。而在RESTful Service中需要指定

这个过程也不复杂，有此类开发经验的人很容易。但是对初次接触REST开发的人来说还是需要费一番周折的。

参考：

http://www.west-wind.com/weblog/posts/2008/Apr/21/jQuery-AJAX-calls-to-a-WCF-REST-Service

JQuery1.4 API手册

MSDN