问在.net中，哪种编程模型适合原型化，但又可重用于生产(用于业务逻辑/数据访问层)

EN

我建议尝试一种分层方法：

• 将您的实体数据模型和验证类放入单独的程序集中
• 将其他业务逻辑放入单独的业务逻辑程序集
• 将您的服务(WCF或WCF数据服务)放入其自己的程序集中

所有这些基础层都与您选择的UI前端技术非常独立。您可以在此处进行选择(例如，用于数据访问的Linq-to-SQL与实体框架；您是否需要基于WCF的服务层，或者您的应用程序是否使用直接DB访问？)或多或少独立于你为UI层放在上面的东西。

在这些基础组件之上：

• 将您的UI创建为Winforms应用程序或ASP.NET (Webforms或MVC) web应用程序(或两者)

如果您有层，并且架构良好，则可以重用大部分代码和业务规则。

尽量只将特定于每种UI技术的东西(Winforms与ASP.NET)放入这些前端演示程序集中。将所有常见的业务规则、验证规则、访问层和服务层分开。

再说一次:你似乎认为“去ASP.NET”排除了使用WCF/WCF数据服务--根本不是！您可以在ASP.NET应用程序中轻松使用来自WCF服务的数据。通过对业务层和服务层进行分层，您不会损失任何东西-这些层可以很容易地在Winforms和ASP.NET应用程序中重用！

下面是一些评论：

原型作为开发生产质量软件的一种方法可能是有问题的，因为原型的本质可能意味着软件和设计质量并不是那么好。根据定义，原型并不意味着具有很高的质量。

如果目标是在早期阶段从目标客户/用户那里获得一些反馈，那么最好不要制作完整的垂直切片原型(例如UI ->业务-> DB)，而是使用可用于探索用户想法的UI模型。样机很灵活，很容易更改，但功能不全，例如没有业务逻辑或持久性。这种方法允许用户了解一些功能，并参与到设计和需求收集过程中。随着需求的变化，它可以快速地更改mock，特别是在没有业务逻辑或数据库代码必须随之更改的情况下。一个UI模拟工具的例子是Balsamiq：

http://www.balsamiq.com/

如果原型的总体目标之一是调查和探索不同的技术选择，那么这些可以独立于UI模型来完成，并且可以以更抽象的方式完成，即纯技术调查，而不是专注于交付可能发生巨大变化的原型的确切需求。UI样机可能会通过用户反馈改变很多，因此将技术调查作为不同的活动可以使这个过程变得更简单，即在早期发现阶段，事情会发生很大变化，因此耦合较少，并且由于UI想法发展如此迅速，必须不断地更改“后端”，这将减慢您的速度。

在加快软件开发速度方面，利用第三方库。如果您正在使用数据库进行持久化，请查看ORM解决方案，它可以极大地减少开发数据访问层所需的工作，例如nHibernate。根据您使用的UI技术，请查看第三方控件库。

在业界，多年来取代原型驱动开发的方法是:敏捷。它寻求通过始终努力交付功能来迎合用户不断变化的需求，但专注于通过TDD等技术开发高质量的软件。