关于抽象工厂、三层架构的项目始终理解不到位，请大牛们点拨一下？？？
前几天在csdn上下项目，是csdn上哪位朋友分享的，先感谢一下。
项目是关于抽象工厂和三层架构的，于是我也下载来研究一下，开始看了老半天，感觉我的理解总是“不踏实”，好像缺少点什么，望大牛可以点拨一下，来个茅塞顿开。。
项目结构原图：
我把主要关于抽象工厂和三层架构的几个模块拿出来画了一下：
先说一下我的理解——各个层的用途（倒过来讲——从底层说起）
AccessDAL——数据访问层（主要用于操作Access数据库）
SQLServerDAL——数据访问层（主要用于操作SQL Server数据库）
FactoryDAL——通过配置文件，决定使用哪个数据访问层。
BLL——业务逻辑层，主要通过FactoryDAL等到确切的数据访问层对象（是AccessDAL中的对象还是SQLServerDAL中的对象）
UI——页面展示（不多说）
我总觉得我还有一下地方没有考虑到，例如第二张图片中的红色框框部分。主要是各层之间对IDAL关系不够理解。。。
———————————————————————分割一下———————————————————————————
先贴一点点代码吧，实在不知道该贴哪儿的代码……
我不是亚亚么？！！！！
呵呵 252456098
[解决办法]
大牛出現了。。
學習一下。。
[解决办法]
1.抽象工厂实际和3层没有直接性的逻辑关系。只能说一些3层设计使用了抽象工厂做手段。
2.lz下的这个例子实际就是petshop的架子，但实际开发中这套架子并不多见，他主要集中在一些新手的项目，和一些大公司的项目中。
新手用是因为这套架子是微软地，但是属于不明就里的照搬
大公司用是因为，他们开发项目有明确的设计周期。那些IDAL，factroy有很长的调研分析阶段。
而petshop用这套东西，一个是微软为了展示他的技术，二是petshop是一个经历了十多年的虚拟demo，他的需求，设计，功能早在10年前就固定下来了，微软所能展示的也就是只能是dal和dalfactory了，至于啥IBIL，IDAL这10多年基本就没变过。
而一般中间层的很少使用这套模型。因为国内的项目很少给你那么长时间做调研分析，也很少给你一个固定不变的需求，在时间不够的情况匆忙上马的IBIL，IDal典型是不合适地，而不断变化的需求也让你去不断更新IBIl，IDal，这很明显也并没有体现啥好处
[解决办法]
我顶一下
[解决办法]
public static IAdbanner CreateAdbanner()
{
string classname = path + ".Adbanner";
return (IAdbanner)System.Reflection.Assembly.Load(path).CreateInstance(classname);
}
我木有记错的话，这个不是反射么？
[解决办法]
其实不管是代码还是设计模式
都是人写的，随便所欲，找到属于自己的，而不是照搬
现有的一些 设计模式只是前面的人用了觉得不错，是某种情况下最好的方式
而在某些情况下就会有很多的人使用
[解决办法]
这个你要知道的是变与不变
petshop这套架子，变的始终是DaL部分，
如今的petshop微软为了展示他的技术，已经发展了N多版本了，从最早地sqlhelp，然后是数据集，接着是linq2sql，现在是EF
你发现没有微软变的始终只是数据提供的DAL部分，可以说在数据提供部分微软这些年做了不少工作，而petshop这个项目也主要是微软为了展示这些技术而做的demo
而petshop项目本身其BIL，Ibil，IDal始终是不变地，所以微软就把其重点放在了这个dal部分
但是实际开发中，DAL变更并不是项目控制的重点，反倒是业务逻辑变更才是项目控制的重点
[解决办法]
谢谢分享
[解决办法]
学习中，谢谢分享
[解决办法]
菜鸟飘过 好好学习
[解决办法]
但是这儿却是通过接口IAdbanner的实例来调用这个方法，接口只不过是定义了这个方法，并没有实现这个方法啊？？？
DataAccess返回的原本是Adbanner类的实例，但是被强转成了IAdbanner类型啊！
该怎么理解？？？
=================================================================
目的是為了BLL與DAL觸藕用的,系統會保持IBLL或IDAL的接口不變,在以後可能系統使用了SQL Server 那你只要實現IDAL,那你就不用做任何的改動就直接切換到以sql server為數據平台的服務器上運行了.
[解决办法]
太复杂了 看不懂
[解决办法]
利用多态实现变化的封装，以及层和层之间的解耦。也就是BLL层实际是对DAL层具体实现的“无知”，这样保证DAL在发生变动时不影响BLL。
[解决办法]
不使用DalFactory和IDAL，支持多种数据库应用的架构
关于三层架构，不得再说一说
企业级开发：怎样缩减7层架构！
一行代码操作表单的三层架构实例下载
[解决办法]
1 这些架构无疑是照搬微软petshop的套路。
2 微软写这个demo是表示“可以这么做”，但并非“必须这么做”。
我看到不少人都喜欢照着（实际是拷贝）petshop搭建项目，实际上，我觉得这种架构根本不适合实际开发。
就拿你的列举的代码上看，
你看 假如ui层需要bll层的adbanner业务类添加一个GetCount(string where)方法;
那么开发者需要做这么几件事，首先，到idal下的iadbanner接口添加方法定义GetCount(string where)；然后，到idal的针对sql server的实现类sqlserverdal下的adbanner，调用sqlhelper实现方法GetCount(string where)，同时，再针对oracle的实现类oracledal下的adbanner，调用oracleHelper实现方法GetCount(string where)，
最后，bll下的adbanner类下定义方法GetCount(string where)添加一行代码，，"转发" dal层的调用。
至此，谢天谢地，ui层终于可以调用GetCount(string where)了。
1 照这个模式开发，就等于是说ui层需要bll提供什么方法，都得走这么一个过程，dal实际上就等同于bll，bll实际上啥也不是，内容空洞，在这里完全可以去掉，ui层直接IDal.GetCount(string where)，架构一样清晰，分层一样利落。
2 server dal 和oracle dal里的代码基本上是一样，区别无非就是ado.net组件的差别，也就是执行sql的sqlhelper里使用system.data.sqlclient组件和system.data.oraclehelper里使用oracleclient组件的差别，实际上这两个命名空间下的组件如sqlconnection,sqlcommand,oracleconnection,oraclecommadd等都继承于system.data.common下的dbconnction,dbcommand,也就是说，利用这些通用ado.net组件编写xxxhelper的话，根本不需要整n个xxxdal，也没有必要定义接口 idal。
前几天我正好写了一篇关于这个话题的文章，http://www.cnblogs.com/lindping/archive/2011/06/27/2090834.html
[解决办法]
表现层 应用层 领域层 基础设施层
依赖注入 仓储
[解决办法]
}
}
[解决办法]
按照我的理解，你的代码如下
Idal:
interface Iuser
{..}
dal
class DalUser:Iuser
{...}
bll:
class xxx
{
Iuser GetUer()
{
//不反射，直接new一个返回
return new DalUser();
}
}
UI层
IUser user = xxx.GetUser();
是否就是你的意思？
