问题描述
使用三层结构开发的项目，有Web版，也有Winform版，内容基本上是一致的。能不能把BLLDAL放在公共处，两者共同引用？可以的话请帮我说下怎么搞，项目的架构应该是怎样的？
解决方案
解决方案二：
添加两个不同的项目就行了啊，一个web,一个winform两个建在同一个解决方案下就行了啊
解决方案三：
开接口，web和winform都通过接口层来调用具体方法
解决方案四：
blldalmodelui这个本身就支持webwinfrom一起上的，你把这些东西全部建立在一个解决方案下面，winfrom，web都要用bll，model就可以了
解决方案五：
BLL基本上是通用的，只是BLL外边一般来说可以包一层“GateWay”层，用来处理接入形式的不同。如果是一个本地应用调用本地的BLL（这种情况在我这里并不适用），那么就可以忽略GateWay层。如果你是通过网络的，那么前端会有一个适配GateWay，服务器端则会有至少一种GateWay。比如说你可能通过80端口、通过web服务形式来发布200个接口功能，同时你又通过6999端口、通过websocket形式在json的基础上扩展自定义信令来发布220个接口功能，然后你的服务器端实际上还接受MSMQ方式的10个命令，还可以通过普通的http网页get方式下载任意图片资源.........面向服务设计开发框架，是要把服务独立出来考虑，因此就是要求你是否了解轻量级的GateWay的设计。此时就不纠结于前端用什么开发工具，而是要看前端能用什么通讯方式跟服务器通讯。
解决方案六：
对于大多数刚学asp.net没有2、3年的程序员来说，他搞不清楚一件事儿，其实他学习的asp.net编程方式也就是刚学winform的人学到的那种调用本地数据库驱动的方式（只不过这个数据库驱动可以远程访问数据库服务器）。他搞不清楚这时候有没有必要使用三层架构。这时候其实倾向于没有必要使用三层架构。只有当你的远程服务增多了时候，你需要将牺牲一点“数据库访问效率”来将系统的吞吐能力大大提高的时候（每一个单机的访问服务都降低了10%，但是整个系统的数据服务能力提高了10倍以上），特别是你模拟服务于不同的前端开发团队，这时候就可以专门成立一个团队（或者小组）负责研发BLL层。
解决方案七：
一个解决方案可以有类库，也可以有winform，更可以有webform……
解决方案八：
简单地说“使用三层结构开发的项目”的做法，简单地动不动就在解决方案下面“放三个工程、或者三个目录”的做法，我其实不知道这有什么。如果你的一个工程在多个解决方案都使用，甚至是单独打包发布到互联网上、供其它不认识的团队去使用，你说这个时候它的功能叫做“BLL层”或者叫做“DAL层”，这个时候它的价值就可以客观衡量。如果是只有自己在一个解决方案里弄三个工程或者三个目录，也就是走走形式、学学（最简单的）理论、孤芳自赏。离三层设计的目标还很远，因为你在此还没有遇到真正的挑战。
解决方案九：
引用楼主xuebao2的回复:
使用三层结构开发的项目，有Web版，也有Winform版，内容基本上是一致的。能不能把BLLDAL放在公共处，两者共同引用？可以的话请帮我说下怎么搞，项目的架构应该是怎样的？
如果人少（只有3个人），并且你就是本地访问的系统，那么不同解决方案里直接加入相同的BLL+DAL工程（完全用不着把BLL和DAL分成两个工程，甚至完全用不着自己开发DAL层），只不过负责前端开发的人只看不改那些与己无关的源代码。如果人多一点，特别是当你使用正规的c/s（前端访问自己公司的server层，而不是直接访问数据库系统）或者b/s方式访问服务的时候，那么前端的工程中只应该有一个分非常简单通用的GateWay层，用来能够方便地（例如只写一句话地）调用服务器端的功能调用。这时候就谈不上”放在公共处“了，而是网络架构了。
解决方案十：
引用6楼starfd的回复:
一个解决方案可以有类库，也可以有winform，更可以有webform……
+1建完之后，学一下怎么引用
解决方案十一：
你可以仔细考虑一下所谓”放在公共处，两者共同引用“这个说法背后的依据，就会发现，这主要是做单机小程序的思路。如果你做b/s上的服务，你的服务是独立对外服务的，不管是javascript、java、c#写的web还是桌面程序都能访问。如果你做桌面的服务也是如此，不管是哪种语言的、不管是web还是桌面的程序都能访问。结果就是，服务器端根本不纠结于客户端是asp.net页面、浏览器端javascript客户端应用，还是wpf、wenform程序的访问。那么如果万一你有一天是做这种开发，你就不提”放在公共处，两者共同引用“这类说法了。
解决方案十二：
真放到一起，那么winform基本上就是sp说的，单机小程序了。。。