62,243
社区成员
发帖
与我相关
我的任务
分享问一个MODEL的问题，关于三层结构的MODEL问题，知道的，进来讨论一下。。有理就给分了。。。。。。。。。。。。。。。。进来讨论吧。
三层结构中，WEB BLL DAL 先说基础模式。其它的先不用讨论。
关于，
WEB MODEL
BLL MODEL
DAL MODEL
这三个MODEL如何命名，管理，相互转化？
分别在单表的情况，多表查询的情况两个情况进行讨论。。。
高手说吧。。
关于，
WEB MODEL
BLL MODEL
DAL MODEL
这三个MODEL如何命名，管理，相互转化？
分别在单表的情况，多表查询的情况两个情况进行讨论。。。
高手说吧。。
...全文
请发表友善的回复…
发表回复
showjim 2014-07-03
- 打赏
- 举报
dbmodel与DAL不是同一层次的东西，好吗？谁人规定dbmodel不能OO？谁人规定只有nosql才能OO？井底之蛙...
wanghui0380 2014-07-03
- 打赏
- 举报
至于其他的俺们也不想说啥了fastCSharp
呵呵+呵呵，应该是和那个PDFXXX一样著名了
wanghui0380 2014-07-03
- 打赏
- 举报
对于你这种论调，我只能以呵呵+呵呵 应对了。请记住你的DAL最早的名字叫什么----“数据持久层”，不是什么“OO模型层”，还面对对象？？？除非你是nosql，否则关系数据库天生就不是对象型滴，你这算脑补么？？
moonwrite 2014-07-03
- 打赏
- 举报
分别在单表的情况，多表查询的情况两个情况进行讨论。。。
多表情况1. 现在的ORM都有导航属性了
2.再定义一个实体
moonwrite 2014-07-03
- 打赏
- 举报
BLL和DAL公用一个Model
Web可能需要自己的ViewModel
怎么转换方便~可以使用一些组件
http://www.cnblogs.com/xishuai/p/3708483.html
当然如果字段和数据库的一致~那么用CodeSmith或T4模版生成
showjim 2014-07-03
- 打赏
- 举报
如果基本业务逻辑层的表格继承自同一dbmodel并且有相同的业务逻辑，还是上面那个列子，那么可以这样定义
public abstract class forumAverage<valueType> : publishData.dataModel.forumAverage.sqlTable<valueType>
where valueType : forumAverage<valueType>
{
//这里是公共业务逻辑处理
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[全 国]
/// </summary>
public class average : forumAverage<average>
{
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[中央]
/// </summary>
public class centralAverage : forumAverage<centralAverage>
{
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[地方]
/// </summary>
public class localAverage : forumAverage<localAverage>
{
}
/// <summary>
/// 各类课本的平均印数、平均印张和平均定价
/// </summary>
public class average : forumAverage<average>
{
}showjim 2014-07-03
- 打赏
- 举报
说到dbmodel（有些人认为不是model），并不是一个字段/属性对应一个列，这些model也不对应实际的表格（而仅仅是一个抽象模型）。下面的代码无关某些人说的业务model，仅仅描述存储结构定义层。比如
/// <summary>
/// 平均印数、平均印张和平均定价
/// </summary>
public abstract class average : year
{
/// <summary>
/// 每种印数（万册）
/// </summary>
public column.average3 Printing;
/// <summary>
/// 每册印张（印张）
/// </summary>
public column.average3 Sheet;
/// <summary>
/// 每册定价（元）
/// </summary>x
public column.average3 Price;
/// <summary>
/// 每印张定价（元）
/// </summary>
public column.average3 SheetPrice;
}
/// <summary>
/// 各类图书的平均印数、平均印张和平均定价
/// </summary>
[sqlTable(Connection = sqlTable.connection.PublishData, CacheType = typeof(fastCSharp.sql.cache.whole.identityArray<,>))]
public partial class forumAverage : average
{
/// <summary>
/// 版块
/// </summary>
[fastCSharp.setup.dataMember(MaxLength = 128)]
public string Forum;
}
/// <summary>
/// 各地区使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[使用《标准书号》部分合计]
/// </summary>
[sqlTable(Connection = sqlTable.connection.PublishData, CacheType = typeof(fastCSharp.sql.cache.whole.identityArray<,>))]
public partial class areaAverage : dataModel.average
{
/// <summary>
/// 版块
/// </summary>
[fastCSharp.setup.dataMember(MaxLength = 128)]
public string Forum;
/// <summary>
/// 区域
/// </summary>
[fastCSharp.setup.dataMember(MaxLength = 32)]
public string Area;
}
/// <summary>
/// 新出+重印+租型 平均数
/// </summary>
[fastCSharp.setup.cSharp.sqlColumn]
public partial struct average3
{
/// <summary>
/// 新出
/// </summary>
public dataMember.average New;
/// <summary>
/// 重印
/// </summary>
public dataMember.average Reprint;
/// <summary>
/// 租型
/// </summary>
public dataMember.average ForRent;
}
/// <summary>
/// 平均值
/// </summary>
[fastCSharp.setup.dataMember(DataType = typeof(int?))]
public partial struct average
{
/// <summary>
/// 整数值
/// </summary>
[fastCSharp.setup.cSharp.json(IsIgnoreCurrent = true)]
private uint? value100;
/// <summary>
/// 是否为空值
/// </summary>
public bool IsNull
{
get { return value100 == null; }
}
/// <summary>
/// 两位小数
/// </summary>
public double Value
{
get { return (uint)value100 / 100.0; }
}
/// <summary>
/// 还原数值
/// </summary>
/// <param name="number">除数</param>
/// <returns></returns>
public double Div(double number)
{
return (uint)value100 / number;
}
public static implicit operator average(int? value) { return new average { value100 = value != null ? (uint?)(int)value : null }; }
public static implicit operator int?(average value) { return value.value100 != null ? (int?)(uint)value.value100 : null; }
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[全 国]
/// </summary>
public class average : publishData.dataModel.forumAverage.sqlTable<average>
{
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[中央]
/// </summary>
public class centralAverage : publishData.dataModel.forumAverage.sqlTable<centralAverage>
{
}
/// <summary>
/// 使用《中国标准书号》各类图书的平均印数、平均印张和平均定价[地方]
/// </summary>
public class localAverage : publishData.dataModel.forumAverage.sqlTable<localAverage>
{
}
/// <summary>
/// 各类课本的平均印数、平均印张和平均定价
/// </summary>
public class average : publishData.dataModel.forumAverage.sqlTable<average>
{
} public class sqlTable<valueType> : publishData.dataModel.forumAverage, fastCSharp.setup.cSharp.sqlTable.ISql<valueType, publishData.dataModel.forumAverage.memberMap>
zhaofeiye 2014-07-03
- 打赏
- 举报
混点分
showjim 2014-07-03
- 打赏
- 举报
瞎鸡巴扯淡你就。
小作坊与小作坊模式是两回事，一堆垃圾凑在一起还是垃圾，不要以为呆在大堆里面就有了莫名的优越感。
请问dbmodel与一个实体几张表有什么关系？请问dbmodel与数据存在哪里有什么关系？请问dbmodel与分布缓存有什么关系？DAL的选择与DBA有什么关系？架构师难道是瞎指挥？
wanghui0380 2014-07-03
- 打赏
- 举报
我其实不知道谁是这东西，不过我知道20人以下的小作坊是你这么搞滴，而真正第项目DAL可不是听你的安排，DAL听DBA和架构师的安排，DBA让你一个实体几张表就几张表，几个实体一张表就一张表，架构师让你把数据存xml就存xml里，让你去远程分布缓存里取你就得去远程分布缓存里取，人家可不根据你这个DAL去安排工作
showjim 2014-07-03
- 打赏
- 举报
我提到的web视图，就是整个网站/应用的 需求数据关系图，这个基本数据图是基于class的，是真实数据的载体。
而外围组件的数据需求（比如存储组件模型、业务组件模型...），应该基于接口或者委托，是需求数据的扩展。
xghabc 2014-07-02
- 打赏
- 举报
顶上去。。。。
wanghui0380 2014-07-02
- 打赏
- 举报
至于UI层面上，我说UI是最难把控和掌握滴，尤其是定制软件，天知道你的客户一拍脑袋会把什么跟什么连接在一起显示
所以这边和逻辑上的model不同也可以想象的出来，所以这里也有转换，这里这个model叫什么其实无所谓，现在有人叫viewmodel，你要这么叫随便你，不过就是个名字而已，但是不管怎么叫他只是逻辑上的model的重新组合和重载，所以我们也并不太在意这块，只要你中间的逻辑model提供完备，UI这块只要符合逻辑都可以随便你去搞（当然要求上违反逻辑滴，这个不是你做错了，就是客户想错了，这个基本没办法，你做错了当然错了，客户错了只能沟通，沟通不了，只能算需求就错了，怨不了实现人员了）
wanghui0380 2014-07-02
- 打赏
- 举报
顺带延伸一下，我们反对一表一实体的原因很简单，因为表结构那是DBA考虑的
而对于逻辑上，一表也许有多个实体，一实体也许有多个表，老p其实也在一些场合表明过他对EF略微有些失望“因为没办法表明继承和多态”，这是老p的说法，这个说法实际上意思就是逻辑上model和dbmodel其实根本就不一样的东西，博客园把这两个混同一起，在项目上自然就产生你的疑问，不一样自然需要转换。但是如果你换过来想，如果你本身就不依赖dbmodel，你本身只依赖逻辑model，那么你就没啥疑问了，nosql当然可以自然表达，但是换到sql不适配，不适配那就不适配呗，下面自己转换去，反正上层根本不依赖他，上层只依赖逻辑上的model而非dbmodel
wangerpang 2014-07-02
- 打赏
- 举报
1。分不分层看你的应用。
2。你可以自己直接实现你的功能，随着需求的变动或者修改，你就会发现你原来的设计要不停的修改，这时你就会知道如何分层，才能让自己的修改代价最小。
以专业开发人员为伍 2014-07-02
- 打赏
- 举报
说到“管理，相互转化？”，这个也确实值得说一下。但是如果知道另外的Model都不是“三层”的Model，显然更会让你集中精力去研究框架。
比如说你研究某一种表现层框架是会花一半经历去研究数据Model，它要求你这样的创建Model；另外一种表现层框架，它建议你用另外一种。
你研究某种DAL层框架也会花一半精力去研究数据建模，你会发现EF是这样建模的，而MongoDb是那样为数据建模的，总之都不一样。
知道了区别，也就知道转化。因为表现层的Model对数据层是完全屏蔽的，DAL层的数据模型对表现层也是完全屏蔽的。在通讯方面，只有三层结构里的Model出现。
wanghui0380 2014-07-02
- 打赏
- 举报
另外在对lz"分别在单表的情况，多表查询的情况两个情况进行讨论。。"滴讨论一下
俺们csdn滴不同于博客园的人，俺工作在第一线，对博客园那种形式大于逻辑的形而上的嗤之以鼻（也许我是这坛子里最旗帜鲜明的反对博客园的人，不过我无所谓，博客园那种的确应该批判），对于你的问题俺们说，如果j基于EF是延后滴，那么你就提供iqueryable<T> 有何不可
在这种角度来看，你什么dal其实就是多余滴，因为EF延后，你完全可以直接提供，后期where，select，join，left join，group joip人家通通可以，你做个固定死滴什么形式上的model没有任何意义
ps：这里的model需要澄清一下，老p说model固定，那是指逻辑上的model，而不是值dbmodel，一表实体也就只能是博客园那些家伙能玩滴出来，实际一线编程人员绝不认为一表一实体是真理
以专业开发人员为伍 2014-07-02
- 打赏
- 举报
model当然可以有很多种。但是“三层”中的model，我们可以独立出来。知道针对数据库每一个数据表的所谓model，以及针对UI每一个窗体控件的ViewModel，跟三层没有必然的联系。虽然他们的名字中也有model这个词儿
以专业开发人员为伍 2014-07-02
- 打赏
- 举报
如果你纠结什么DAL层，那么你随便整什么Model。但是这跟三层的“Model”没有什么必然的关系。比如说你使用EF，或者别的什么模式，那都是你自己要使用数据库驱动而整的什么class，跟三层无关。有些人非要围绕着每一个数据库表再去定义什么class，那是他自己愿意瞎折腾。讲求效率的人，直接在BLL中使用ADO.NET或者EF之类的，直接读取数据，直接创建Model对象（或者对象集合）。
同样地，表现层的ViewModel跟三层的Model也没有必然的关系。比如说我有一个页面是显示“好友列表”的，那么我的这个界面组件的ViewMode就是用于给界面绑定列表数据、以及“刷新、加载更多、打开好友窗口”等功能的。协调多种界面的数据对象，以及打开另一个窗口的操作，都是ViewModel上定义的，而界面的列表的SourceItems属性以及几个按钮的Click事件跟ViewModel绑定，这样就能在我们剥离开美工技术以外直接定义一些编程方法。
wanghui0380 2014-07-02
- 打赏
- 举报
其实我能明白老p的说法，他的model其实基于业务逻辑，业务逻辑如此当然没啥可说滴，只是lz这种问法，明显是博客园那种形式大于逻辑的搞法，如果是博客园那种形式大于逻辑的弄法，自然各自管各自滴，毕竟形式主义的弊病就是只管形式，不管逻辑
加载更多回复（32）
