读书人

关于抽象工厂、三层架构的项目始终了解

发布时间: 2014-01-17 00:06:00 作者: rapoo

关于抽象工厂、三层架构的项目始终理解不到位,请大牛们点拨一下???
前几天在csdn上下项目,是csdn上哪位朋友分享的,先感谢一下。

项目是关于抽象工厂和三层架构的,于是我也下载来研究一下,开始看了老半天,感觉我的理解总是“不踏实”,好像缺少点什么,望大牛可以点拨一下,来个茅塞顿开。。

项目结构原图:
关于抽象工厂、三层架构的项目始终了解不到位,请大牛们点拨一下?

我把主要关于抽象工厂和三层架构的几个模块拿出来画了一下:
关于抽象工厂、三层架构的项目始终了解不到位,请大牛们点拨一下?

先说一下我的理解——各个层的用途(倒过来讲——从底层说起)
AccessDAL——数据访问层(主要用于操作Access数据库)
SQLServerDAL——数据访问层(主要用于操作SQL Server数据库)
FactoryDAL——通过配置文件,决定使用哪个数据访问层。
BLL——业务逻辑层,主要通过FactoryDAL等到确切的数据访问层对象(是AccessDAL中的对象还是SQLServerDAL中的对象)
UI——页面展示(不多说)

我总觉得我还有一下地方没有考虑到,例如第二张图片中的红色框框部分。主要是各层之间对IDAL关系不够理解。。。
———————————————————————分割一下———————————————————————————


先贴一点点代码吧,实在不知道该贴哪儿的代码……


不过sp大哥说的有道理 我虚心接受,当时做这个只是出于无聊,并不是说做什么
现在在做用户操作性强的东西 已经摈弃这个模式了 上次谁说要源码学习 我就给贴了一下地址
想不到今天一打开觉得好面熟
菜鸟飘过 好好学习 天天向上

[解决办法]
引用:
引用:

汗 我做的东西你咋下载了?

我被拍砖了
不过sp大哥说的有道理 我虚心接受,当时做这个只是出于无聊,并不是说做什么
现在在做用户操作性强的东西 已经摈弃这个模式了 上次谁说要源码学习 我就给贴了一下地址
想不到今天一打开觉得好面熟
菜鸟飘过 好好学习 天天向上


嘿嘿,谢谢你啊!!!……



我不是亚亚么?!!!!
呵呵 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类型啊!

该怎么理解???

=================================================================
目的是了BLLDAL藕用的,系保持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
[解决办法]
表现层 应用层 领域层 基础设施层

依赖注入 仓储


[解决办法]

引用:
谢谢你的回答!!!

其实我上面已经说清楚了,我只是为了学一点技术点而去研究这个项目,比如,我想了解这个项目里面应用接口的思想,我并不是说开发项目死活要按照这个结构来做。。。


前段时间刚好参与了公司的一个项目开发,这种照搬petshop的写法令我不生厌烦,于是自己写了个通用数据访问组件,今天上csdn看到你的帖子,一看你的图,跟我的项目以及petshop又是一模一样,慨叹用心写代码的人太少了。

[解决办法]
就IDAL接口的问题,不同的人有不同的看法,从我的经验上来看,这与组件调用是有关系的,假设我们的项目界面层组件以F打头,业务层组件以T打头,数据层以B打头,可能会出现组件F001调用组件T001,T002,T001调用B001的情况。
假设我们有个对象为USER, 那么在T001中存在T_USER, 在B001会出现B_USER。

但从编程角度讲,我们都希望实体类的数据只出现一次,即只出现在B_USER中。那么T_USER就只能引用B_USER对象而已,再进行处理。

这样问题就来了。

如果F001需要调用T_USER,并且不想引用B001组件怎么办?

一种方法是在T_USER中将B_USER调用时,仅作内部对象处理,对USER中的属性再重新包装显示 public Class T_User
{
private B_User _Buser;
public string Name
{
get;
set;
}
...(会不会很累?)
}

另一种方法是调用一个公用的接口. T001,B001,F001都引用IDAL,这样F001就不用引用B001组件了。
Public class T_User
{
private IBUser _Buser;
public IBUser BUser
{
get;
set;


}
}
[解决办法]
按照我的理解,你的代码如下
Idal:
interface Iuser
{..}

dal
class DalUser:Iuser
{...}

bll:
class xxx
{
Iuser GetUer()
{
//不反射,直接new一个返回
return new DalUser();
}
}

UI层

IUser user = xxx.GetUser();


是否就是你的意思?

读书人网 >.NET

热点推荐