在Suteki.Shop中Model的原型是基于Linq to SQL创建的，其dbml文件位于Suteki.Shop\Shop.dbml。
而Suteki.Shop在此文件的基本上，以"partial class "的方式在Suteki.Shop\Model文件夹下创建了相应
的类文件以扩展Shop.dbml中Model类的一些方法和属性声明，如下图：
为了便于大家理解，下面以Model中的Product.cs为例进行说明。
Product是对网站中所销售商品的数据信息类。在其中定义了一些属性（声明在Shop.dbml中）：
private int _CategoryId; //产品所属分类ID
private string _Name; //产品名称
private string _Description;//产品描述
private decimal _Price; //产品价格
private int _Position; //在列表中的位置
private int _Weight; //重量
private bool _IsActive; //当前是否激活显示
private string _UrlName; //产品的URL链接
而Product.cs这个文件其实是以partial方式对Shop.dbml中的Product类的"扩展",下面是其实现代码：
{
partial void OnNameChanging(string value)
{
value.Label("Name").IsRequired();
}
partial void OnNameChanged()
{
UrlName = Name.ToUrlFriendly();
}
partial void OnDescriptionChanging(string value)
{
value.Label("Description").IsRequired();
}
public bool HasMainImage
{
get
{
return this.ProductImages.Count > 0;
}
}
public Image MainImage
{
get
{
if (HasMainImage) return this.ProductImages.InOrder().First().Image;
return null;
}
}
public bool HasSize
{
get
{
return this.Sizes.Active().Count() > 0;
}
}
public Size DefaultSize
{
get
{
if (this.Sizes.Count() == 0) throw new ApplicationException("Product has no default size");
return this.Sizes[0];
}
}
public string IsActiveAsString
{
get
{
if (IsActive) return string.Empty;
return " Not Active";
}
}
public static Product DefaultProduct(int parentCategory, int position)
{
return new Product
{
ProductId = 0,
CategoryId = parentCategory,
Position = position
};
}
}
首先要说明的是OnNameChanging方法，该方法的声明如下(位于Shop.dbml中)：
并且在dbml中相应的产品"Name"属性中对其进行调用：
public string Name
{
get
{
return this._Name;
}
set
{
if ((this._Name != value))
{
this.OnNameChanging(value);
this.SendPropertyChanging();
this._Name = value;
this.SendPropertyChanged("Name");
this.OnNameChanged();
}
}
}
这样做的目的就是在产品的名称发生变更时调用该方法以进行处理，当然该set中还有一些
其它方法的调用，这里要不多做说明了。下面接着看一下partial类中OnNameChanging方法所做
的工作：
{
value.Label("Name").IsRequired();
}
看到这里，如果大家之前看过我写的这篇文章的话（里面的ValidationProperty类），就会
清楚这里是要对当前传入的产品名称变量进行“是否为空”的校验了。同理，还有对产品描述的
验证规则：
{
value.Label("Description").IsRequired();
}
这里要说明的一点就是在“数据验证”一文中所介绍的“用户信息验证”与上面所使用的信
息验证规则的绑定方式有所不同。即“用户信息验证”是在相应Action中调用Validate()方法实
现的，而上面的这种方式是dbml中以“partial method”方式实现并在相应对象属性发生变化是
触发。
同样，在商品的partial类声明中还包括一些其它的属性如：HasMainImage，DefaultSize，
HasSize等。
当然，如果您在实际开发中未使用LinqToSql的话，IDE就不会为您生成相应的数据实体类代
码，这时我们可以参考另一个MVC示例项目“MVCStore”的做法，直接在Model中创建并定义相应
的实体类，其实我个人是比较喜欢MVCStore的那种实体类结构，它Model中数据都是只有属性没有
方法。巧的是MVCStore中也有一个叫“Product”的Model类，其位于:Commerce.Data\Model\
Product.cs,大家可以下载其代码看一下即可。
除了使用“partial”方式对Shop.dbml所生成的实体类代码进行完善扩展之外，Suteki.Shop
项目也采用了大多数MVC示范中所使用的“Repository”模式对Model中类的CRUD方法进行封装，
只不过它做的更“高明”一些，即使用接口（和泛型接口）方式统一定义了CRUD的名称，其类图：
注：Suteki.Shop的作者在这篇文章中提到过，这种架构方式是吸取了Ayende 这篇文章的思想。而Ayende就是
Rhino.Commons,Rhino Mocks等软件作者。
下面是其相关的接口声明：
{
T GetById(int id);
IQueryable<T> GetAll();
void InsertOnSubmit(T entity);
void DeleteOnSubmit(T entity);
[Obsolete("Units of Work should be managed externally to the Repository.")]
void SubmitChanges();
}
public interface IRepository
{
object GetById(int id);
IQueryable GetAll();
void InsertOnSubmit(object entity);
void DeleteOnSubmit(object entity);
[Obsolete("Units of Work should be managed externally to the Repository.")]
void SubmitChanges();
}
做为实现上面两个接口的“Repository”类，其承担了对CRUD的具体操作逻辑实现。
{
readonly DataContext dataContext;
public Repository(IDataContextProvider dataContextProvider)
{
dataContext = dataContextProvider.DataContext;
}
public virtual T GetById(int id)
{
var itemParameter = Expression.Parameter(typeof(T), "item");
var whereExpression = Expression.Lambda<Func<T, bool>>
(
Expression.Equal(
Expression.Property(
itemParameter,
typeof(T).GetPrimaryKey().Name
),
Expression.Constant(id)
),
new[] { itemParameter }
);
return GetAll().Where(whereExpression).Single();
}
public virtual IQueryable<T> GetAll()
{
return dataContext.GetTable<T>();
}
public virtual void InsertOnSubmit(T entity)
{
GetTable().InsertOnSubmit(entity);
}
public virtual void DeleteOnSubmit(T entity)
{
GetTable().DeleteOnSubmit(entity);
}
public virtual void SubmitChanges()
{
dataContext.SubmitChanges();
}
public virtual ITable GetTable()
{
return dataContext.GetTable<T>();
}
IQueryable IRepository.GetAll()
{
return GetAll();
}
void IRepository.InsertOnSubmit(object entity)
{
InsertOnSubmit((T)entity);
}
void IRepository.DeleteOnSubmit(object entity)
{
DeleteOnSubmit((T)entity);
}
object IRepository.GetById(int id)
{
return GetById(id);
}
}
在上面的类图中，还有两个类也很重要，其中IRepositoryResolver是一个分析器接口，其定义了
“传入一个type类型并在Castle容器中获取该type组件实例的方法声明”，而作为其接口具体实现，
“RepositoryResolver”的实现代码如下：
{
private readonly IKernel kernel;
public RepositoryResolver(IKernel kernel)
{
this.kernel = kernel;
}
public IRepository<T> GetRepository<T>() where T : class
{
Type repositoryType = typeof(IRepository<>).MakeGenericType(new[] { typeof(T) });
var repository = kernel.Resolve(repositoryType) as IRepository<T>;
if (repository == null)
{
throw new ApplicationException(StringExtensions.With("Could not find IRepository<{0}> in kernel", typeof(T).Name));
}
return repository;
}
public IRepository GetRepository(Type type)
{
Type repositoryType = typeof(IRepository<>).MakeGenericType(new[] { type });
var repository = kernel.Resolve(repositoryType);
if (repository == null)
{
throw new ApplicationException("Could not find IRepository<{0}> in kernel".With(type.Name));
}
if ((repository as IRepository) == null)
{
throw new ApplicationException("The repository that implements IRepository<{0}> does not implement IRepository".With(type.Name));
}
return (IRepository)repository;
}
}
上面的部分代码涉及到了castle框架的核心功能，可以参见我写的这篇文章即可。大家只要
知道其实现的与我们以前“使用反射方式动态生成相应类实例”的目的相同就行了。
通过上面这几个类，我们为Model中的类提供了“CRUD”方法，这要比之前我所看到的一些
MVC示例相应中的Repository模式实现的要好一些。当然我猜测这种实现也是有性能问题的，比
如说对反射的使用，希望借助castle框架能将这个问题化解。
有了“Repository”类的帮助，让“Repositories”下的文件夹中的文件少了许多，当然上
面的接口方法未必就能把所有的CRUD操作全部覆盖，比如Product就需要有这样一个功能，即按
“商品所属分类”来获取同一类下的所有商品。而这个功能的实现最终还是要在Repositories
文件夹下创建一个类，名为“ProductRepositoryExtensions”：
{
public static IQueryable<Product> WhereCategoryIdIs(this IQueryable<Product> products, int categoryId)
{
return products.Where(p => p.CategoryId == categoryId);
}
}
但这已经是比“实现所有的CRUD方法的代码”那种情况下的行数少了许多了。
有了这种实现方式之后，就可以在Controller中定义相应的Model Repository实例了，其
行如（Suteki.Shop\Controllers\ProductController.cs）：
{
readonly IRepository<Product> productRepository;
readonly IRepository<Category> categoryRepository;
}
看到这里，大家应该基本搞清楚该项目中Model和相关的CRUD方法的实现原理了。下面接着再介
绍一下项目中Services的实现。
首先，可以说其所有Service都有相关的接口进行定义。
以UserService类为例（Suteki.Shop\Services\UserService.cs），其实现了“IUserService”
接口，如下：
{
User CreateNewCustomer();
User CurrentUser { get; }
void SetAuthenticationCookie(string email);
void SetContextUserTo(User user);
void RemoveAuthenticationCookie();
string HashPassword(string password);
bool Authenticate(string email, string password);
}
这样做的原因相信大家都清楚， 就是将来如果业务规则变化时(对应service接口实现类也要发
生变化)，这时不需要真正修改已有的代码，只需再开发一个相应的实现类即可满足需求，这种扩展
方式也是与设计模式中的思想相符合的。除此之外，我再谈一下我对该项目中Service实现的一些个
人观点：
Suteki.Shop对于其Service的封装我认为并不好，原因就在于“Model中是否应该包括业务逻辑”
这个问题上，我本人感觉对于小项目而言（Suteki.Shop，MVCStore就是这样的小项目），还真谈不
上什么充血模型。能把一个贫血模型实现并用好了就完全可以了。而Suteki.Shop中的Model中过多的
注入了方法代码，其中有些应该是放在Service中。
这一点我是强烈建议参考MVCStore下的“Commerce.Services”这个项目的实现，其实现的方式
我感觉非常符合当下SOA倡导的架构方式。有关这方面的内容我在这篇文章中就已阐述，就不做说明了。
好了，今天的内容就先到这里了。
原文链接: http://www.cnblogs.com/daizhj/archive/2009/05/31/1455867.html
作者: daizhj,代震军,LaoD
Tags: mvc,Suteki.Shop