走向ASP.NET架构设计第三章:分层设计,初涉架构(后篇)

  接上篇

  4.数据访问层设计

  数据访问层,这块要说的不多。但是要澄清一点:数据访问不一定就是访问数据库,虽然多数的情况下,我们确实把数据存储在数据库中。

  这里我们用数据库存储数据,并且用Linq To Sql来进行数据访问操作。

  下面我们就来实现数据操作的一些代码:

public class ProductRepository : IProductRepository

{

public IList<Model.Product> FindAll()

{

var products = from p in new ShopDataContext().Products

select new Model.Product

{

Id = p.ProductId,

Name = p.ProductName,

Price = new Model.Price(p.RRP, p.SellingPrice)

};

return products.ToList();

}

}

  5. 显示层设计

  我们这里用Model-View-Presenter模式把显示逻辑从UI层中分离出来,成为显示层。其实这样做的好处:方便单元测试,同时也让我们可以换不同的View来显示,例如我们可以换成aspx的页面显示,也可以用WinForm来显示。关于MVP的详细知识,我会在后续的文章中后慢慢的讲述,本篇只是”初涉架构”----相当于把后续文章的知识都提了一下。

  通过看代码来讲述。我们在ASPPatterns.Chap3.Layered.Presentation项目加入一个接口类:IProductListView

public interface IProductListView

{

void Display(IList<ProductViewModel> Products);

Model.CustomerType CustomerType { get; }

string ErrorMessage { set; }

}

  这个接口会被ASPX的Web Form来实现。下面我们就来创建一个ProductListPresenter来连接View和Service。Presenter负责把数据从service拿来,然后交给View去显示。代码如下:

public class ProductListPresenter

{

private IProductListView _productListView;

private Service.ProductService _productService;

public ProductListPresenter(IProductListView ProductListView, Service.ProductService ProductService)

{

_productService = ProductService;

_productListView = ProductListView;

}

public void Display()

{

ProductListRequest productListRequest = new ProductListRequest();

productListRequest.CustomerType = _productListView.CustomerType;

ProductListResponse productResponse = _productService.GetAllProductsFor(productListRequest);

if (productResponse.Success)

{

_productListView.Display(productResponse.Products);

}

else

{

_productListView.ErrorMessage = productResponse.Message;

}

}

}

  这样实现之后,我们现在就可以编写一些测试的代码来测试数据取的是否正确,此时我们不一定非得用页面的显示才知道数据的正确性。而且这样实现的好处之前也提过:我们可以把数据给WPF的界面显示,或者给WinForm的界面显示。

  6.UI层设计

  最后不管怎么样,我们还是需要显示一下数据的。界面如下:

  ASPX页面的代码如下:

public partial class _Default : System.Web.UI.
Page, IProductListView

{

private ProductListPresenter _presenter;

protected void Page_Init(object sender, EventArgs e)

{

_presenter = new ProductListPresenter(this, ObjectFactory.GetInstance<Service.ProductService>());

this.ddlCustomerType.SelectedIndexChanged += delegate { _presenter.Display();};

}

protected void Page_Load(object sender, EventArgs e)

{

if (Page.IsPostBack != true)

_presenter.Display();

}

public void Display(IList<ProductViewModel> Products)

{

rptProducts.DataSource = Products;

rptProducts.DataBind();

}

public CustomerType CustomerType

{

get { return (CustomerType)Enum.ToObject(typeof(CustomerType), int.Parse(this.ddlCustomerType.SelectedValue) ); }

}

public string ErrorMessage

{

set { lblErrorMessage.Text = String.Format("<p><strong>Error</strong><br/>{0}<p/>", value); }

}

}

  希望大家看到上面一堆代码不要晕,下面就通过一个图来讲述一下整个流程:  

  Page在页面的初始化的时候创建一个ProductListPresenter的实例,并且我们通过StructureMap的ObjectFactory.GetInstance方法得到了一个门户的ProductService。Default页面把任何对他的事件的调用委托给了Presenter,也就是说,我们基本上不在Default的页面代码后面做什么逻辑处理,这一切都放在Presenter里面。

  最后我们设计的结构就很利于测试和维护,也有很强的扩展性。

  本篇(前。中,后篇)就到这里了,还是那句话:把三篇连在一起看,多琢磨下代码,有什么问题大家可以留言!多谢支持! :)

时间: 2024-07-31 20:13:05

走向ASP.NET架构设计第三章:分层设计,初涉架构(后篇)的相关文章

走向ASP.NET架构设计第三章:分层设计,初涉架构(前篇)

本篇主要讲述ASP.NET应用中如何进行逻辑分层.本篇的前篇会从Smart UI 反模式和它的一些缺点开始讲述,然后一步步的讲述如何逻辑分层,而且在后篇中也会给出一个ASP.NET设计中常用的仅供参考的分层架构的Demo. 一个稳定和易维护的系统必须建立在一个好的基础之上.计划和设计一个好的架构对一个项目的成败起着至关重要的作用.可能在我们一般做项目的时候,经验告诉我们:3层,N层的设计,基本就能把问题解决了,很多的情况确实是这样的.在提出一个设计的时候,常常要考虑为什么要这样划分结构,而且常常

架构漫谈(三):如何做好架构之识别问题

原文:架构漫谈(三):如何做好架构之识别问题 架构漫谈是由资深架构师王概凯Kevin执笔的系列专栏,专栏将会以Kevin的架构经验为基础,逐步讨论什么是架构.怎样做好架构.软件架构如何落地.如何写好程序等问题. 本文是漫谈架构专栏的第三篇.接之前的第二篇,作者将会讨论如何做好架构,并根据实际经验分析如何找出实际工作中需要解决的问题. 按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题.一般来说,如果把真正的问题找到,那么问题就已经解决了80%了.这个能力基本上就决定了架构师的水平.

一起谈.NET技术,走向ASP.NET架构设计——第三章:分层设计,初涉架构(中篇)

1.阐明示例需求 本篇还是用之前的电子商务网站中的一个简单的场景来讲述:在页面上需要显示产品的列表信息.并且根据产品的类型不同,计算出相应的折扣. 在上篇中,我们已经设计项目的逻辑分层.我们再来回顾下: 可能有的朋友认为从Smart UI立刻跳到这种分层设计,似乎快了些.其实也算是一个思想的跳跃吧.下面就来看看这种分层是如何解决之前Smart UI的问题的. 2.业务层设计 记得在之前的Smart UI的例子中,程序的业务逻辑是直接写在了ASPX页面后面的cs代码中的.现在,采用分层的方法,我们

走向ASP.NET架构设计第三章:分层设计,初涉架构(中篇)

1.阐明示例需求 本篇还是用之前的电子商务网站中的一个简单的场景来讲述:在页面上需要显示产品的列表信息.并且根据产品的类型不同,计算出相应的折扣. 在上篇中,我们已经设计项目的逻辑分层.我们再来回顾下: 可能有的朋友认为从Smart UI立刻跳到这种分层设计,似乎快了些.其实也算是一个思想的跳跃吧.下面就来看看这种分层是如何解决之前Smart UI的问题的. 2.业务层设计 记得在之前的Smart UI的例子中,程序的业务逻辑是直接写在了ASPX页面后面的cs代码中的.现在,采用分层的方法,我们

一起谈.NET技术,走向ASP.NET架构设计——第四章—业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在

走向ASP.NET架构设计第七章:阶段总结,实践篇(中篇)

服务层(中篇) 上一篇文章中,我们已经讲述了业务逻辑层和数据访问层层的设计和编码,下面我们就来讲述服务层的设计.如我们之前所讨论的:服务层想客户端暴露简单易用的API. 如下图所示: 在上图中: 1. ASPPatterns.Chap6.EventTickets.Contract: 这个类库中定义了服务层的接口契约. 2. ASPPatterns.Chap6.EventTickets.Service:这个类库中包含了上面接口契约的实现类以及业务逻辑的协调和数据的持久化和返回数据 3. ASPPa

一起谈.NET技术,走向ASP.NET架构设计——第七章:阶段总结,实践篇(中篇)

服务层(中篇) 上一篇文章中,我们已经讲述了业务逻辑层和数据访问层层的设计和编码,下面我们就来讲述服务层的设计.如我们之前所讨论的:服务层想客户端暴露简单易用的API. 如下图所示: 在上图中: 1. ASPPatterns.Chap6.EventTickets.Contract: 这个类库中定义了服务层的接口契约. 2. ASPPatterns.Chap6.EventTickets.Service:这个类库中包含了上面接口契约的实现类以及业务逻辑的协调和数据的持久化和返回数据 3. ASPPa

&amp;gt; 前言(补充) 和第三章 第一个C#程序(rainbow 翻译)(来自重粒子空间)

程序 <<展现C#>> 前言(补充) 和第三章 第一个C#程序(rainbow 翻译)   出处:http://www.informit.com/matter/ser0000001/chapter1/ch03.shtml 正文: 前言0.1  提要    欢迎阅读<展现 C#>(Presenting C#).这本书是你提高企业编程语言的一条捷径.这种企业编程语言带有下一代编程语言服务运行时(NGWS Runtime):C#(发音"C sharp").

走向ASP.NET架构设计第四章业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在