62,041
社区成员
发帖
与我相关
我的任务
分享关于MVC的分层问题
MVC新手请教，我想沿用三层架构的思想，但是MVC的模型层既包括了三层里的Model BLL DAL三个层,数据操作用的是EF。有没有办法把EF层生成的Model独立出一个层啊。因为Model不仅仅是BLL DAL才访问的，几乎所有的层都要用到这个层，而且有些功能要有一些独立的Model(并不是只与数据库表一一对应)。又或者提供以下 大家的设计方法。求教！
...全文
请发表友善的回复…
发表回复
niyicms 2012-09-14
- 打赏
- 举报
都是层次很低地纠结在几乎是只有“数据库查询”方面，而根本没有UI层和业务逻辑层架构知识。
非常赞成这个观点。的确太过关注只是数据库查询。但又觉得数据库查询是根本，但它的结构，对整个程序的结构也有很大影响。
非常赞成这个观点。的确太过关注只是数据库查询。但又觉得数据库查询是根本，但它的结构，对整个程序的结构也有很大影响。
我就是大神 2012-09-13
- 打赏
- 举报
关注此帖后续发展
种草德鲁伊 2012-09-13
- 打赏
- 举报
[Quote=引用 10 楼 的回复:]
你用不着吹大牛,亮出你的观点和代码范例,
坛子里,我也贴过不止一次的有关我们的MVC系统的代码,
[/Quote]
你把方法签名称为代码，那我的代码 MvcApp.Run()， OK？
你用不着吹大牛,亮出你的观点和代码范例,
坛子里,我也贴过不止一次的有关我们的MVC系统的代码,
[/Quote]
你把方法签名称为代码，那我的代码 MvcApp.Run()， OK？
缪军 2012-09-13
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
要是把除了编译的.net程序集以外的东西都不称为“代码”,那你说什么都行。
[/Quote]
除了.net以外的都不是代码?搞笑否?
你用不着吹大牛,亮出你的观点和代码范例,
我说的是我的观点,并且是我们目前的生产手段,
坛子里,我也贴过不止一次的有关我们的MVC系统的代码,
我早就说过,微软asp.netMVC范例的代码根本就不是MVC设计模式,
把数据相关的东西和业务相关的东西写在视图和视图控制器中,
那干脆就不要号称MVC了,这种分层没有任何可重用的价值
要是把除了编译的.net程序集以外的东西都不称为“代码”,那你说什么都行。
[/Quote]
除了.net以外的都不是代码?搞笑否?
你用不着吹大牛,亮出你的观点和代码范例,
我说的是我的观点,并且是我们目前的生产手段,
坛子里,我也贴过不止一次的有关我们的MVC系统的代码,
我早就说过,微软asp.netMVC范例的代码根本就不是MVC设计模式,
把数据相关的东西和业务相关的东西写在视图和视图控制器中,
那干脆就不要号称MVC了,这种分层没有任何可重用的价值
种草德鲁伊 2012-09-13
- 打赏
- 举报
要是把除了编译的.net程序集以外的东西都不称为“代码”,那你说什么都行。
种草德鲁伊 2012-09-13
- 打赏
- 举报
[Quote=引用 7 楼 的回复:]
EF那个东西根本就不是MVC中的Model，
所谓强类型数据集根本就是ado基础上的倒退，
本来ado已经为我们实现了数据无关的DA（自动匹配数据结构）
很多程序员自己手工编写硬编码（例如：3楼的代码），却偏偏说ADO不够OO
[/Quote]
整个系统就是把数据呈递到界面上么，那业务逻辑到底做了什么？它完全不知道datatable里面有什么，它什么也不做，就是把datatable传来传去。
EF那个东西根本就不是MVC中的Model，
所谓强类型数据集根本就是ado基础上的倒退，
本来ado已经为我们实现了数据无关的DA（自动匹配数据结构）
很多程序员自己手工编写硬编码（例如：3楼的代码），却偏偏说ADO不够OO
[/Quote]
整个系统就是把数据呈递到界面上么，那业务逻辑到底做了什么？它完全不知道datatable里面有什么，它什么也不做，就是把datatable传来传去。
缪军 2012-09-13
- 打赏
- 举报
[Quote=引用 4 楼 的回复:]
MVC层传递的都是强类型集合吧，我就觉得MVC能获得客户端提交的数据时强类型集合用得好爽，用DataTable传递不了强类型数据，还得转，很麻烦。 ---- 求教用了EF之后Model层应该放哪？
[/Quote]
EF那个东西根本就不是MVC中的Model，
所谓强类型数据集根本就是ado基础上的倒退，
本来ado已经为我们实现了数据无关的DA（自动匹配数据结构）
很多程序员自己手工编写硬编码（例如：3楼的代码），却偏偏说ADO不够OO
MVC层传递的都是强类型集合吧，我就觉得MVC能获得客户端提交的数据时强类型集合用得好爽，用DataTable传递不了强类型数据，还得转，很麻烦。 ---- 求教用了EF之后Model层应该放哪？
[/Quote]
EF那个东西根本就不是MVC中的Model，
所谓强类型数据集根本就是ado基础上的倒退，
本来ado已经为我们实现了数据无关的DA（自动匹配数据结构）
很多程序员自己手工编写硬编码（例如：3楼的代码），却偏偏说ADO不够OO
以专业开发人员为伍 2012-09-12
- 打赏
- 举报
其实从“三层”到“mvc”，我们看到有很多搞繁琐的做法。一个简单的观点就能分辨清楚，就是那种不正常的宣传方法，往往都是层次很低地纠结在几乎是只有“数据库查询”方面，而根本没有UI层和业务逻辑层架构知识。遇到这个时候，除非你能够真的参与到一个有至少一位真正架构师参与编程的实际项目中，否则很难了解真正该从哪里入手去分层。
以专业开发人员为伍 2012-09-12
- 打赏
- 举报
首先要搞明白你一个问题：你是每一个交互动作都刷新一下页面吗？
如果不是，那么你应该把精力放在从交互界面的技术出发上。当你以html/javascript编程为前端交互界面编程手段时，跟asp.net mvc的所谓交互操作ui层就完全是无关的了。你需要花精力去考虑jascript/ajax编程中的分层问题，这时候最好简化服务端数据操作的层次，不要去管什么mvc。
如果不是，那么你应该把精力放在从交互界面的技术出发上。当你以html/javascript编程为前端交互界面编程手段时，跟asp.net mvc的所谓交互操作ui层就完全是无关的了。你需要花精力去考虑jascript/ajax编程中的分层问题，这时候最好简化服务端数据操作的层次，不要去管什么mvc。
kissdodog 2012-09-12
- 打赏
- 举报
MVC层传递的都是强类型集合吧，我就觉得MVC能获得客户端提交的数据时强类型集合用得好爽，用DataTable传递不了强类型数据，还得转，很麻烦。 ---- 求教用了EF之后Model层应该放哪？[Quote=引用 3 楼 的回复:]
引用 1 楼 的回复:
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
那就不会出现 dt[0]["Id"], xml.SelectNode, json.XXX 这样的东西了？
服务的细节别人不知道，它自己也不知道？业务逻辑就是把d……
[/Quote]
引用 1 楼 的回复:
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
那就不会出现 dt[0]["Id"], xml.SelectNode, json.XXX 这样的东西了？
服务的细节别人不知道，它自己也不知道？业务逻辑就是把d……
[/Quote]
种草德鲁伊 2012-09-12
- 打赏
- 举报
[Quote=引用 1 楼 的回复:]
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
[/Quote]
那就不会出现 dt[0]["Id"], xml.SelectNode, json.XXX 这样的东西了？
服务的细节别人不知道，它自己也不知道？业务逻辑就是把datatable传来传去？
还是你所说的程序只有抽象，完全没有实现？
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
[/Quote]
那就不会出现 dt[0]["Id"], xml.SelectNode, json.XXX 这样的东西了？
服务的细节别人不知道，它自己也不知道？业务逻辑就是把datatable传来传去？
还是你所说的程序只有抽象，完全没有实现？
xml111024 2012-09-12
- 打赏
- 举报
只要不做DBSET，就不会和数据库打交道。
缪军 2012-09-12
- 打赏
- 举报
MVC设计模式下：
Model：描述的是业务逻辑，而不是所谓的User，Customer这些东西
比如一个Model可以叫做：单据登记业务，或者单据查询业务，
它们是服务的提供者，而不是数据提供者
View：只呈现了服务的外观，并不知道服务的细节，更不知道数据的细节
Controller分为：ModelDrv（模型控制器）和ViewDrv（视图控制器），
模型控制器负责业务逻辑的组装，
试图控制器负责创建和更新视图以及创建更新模型
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
Model：描述的是业务逻辑，而不是所谓的User，Customer这些东西
比如一个Model可以叫做：单据登记业务，或者单据查询业务，
它们是服务的提供者，而不是数据提供者
View：只呈现了服务的外观，并不知道服务的细节，更不知道数据的细节
Controller分为：ModelDrv（模型控制器）和ViewDrv（视图控制器），
模型控制器负责业务逻辑的组装，
试图控制器负责创建和更新视图以及创建更新模型
MVC传载数据用DataTable，XML，JSON都可以，EF的那些用不上，
数据对象是在运行时刻由控制器根据Model的描述自动匹配的，
程序中根本就不会出现User.Id这种东西
