you can check the enterprise samples in visual studio.net such as duwamish, and use it as a start point.Enterprise Design using C# (wrox) Patterns of Enterprise Applicatoin Architecture(for general application architecuture)msdn.microsoft.com has a column called Patterns and Practice, you can find useful information there. (i.e. patterns for ui layer ,mvc/page controller/front controoler)
你看下自带的例子！Duwamish 7.0 CS 里面有很详细的啦！
TO: thetuxedo(Matrix Reloaded 在书店上找不到。偶英文不太好。不想看原版。有没有中文版的To:浩子。 这个我知道。不过看源代码太累了。有没有介绍的书。上手快一点。
Patterns of Enterprise Applicatoin Architecture(for general application architecuture)msdn.microsoft.com has a column called Patterns and Practice, you can find useful information there. (i.e. patterns for ui layer ,mvc/page controller/front controoler)
里面有很详细的啦！
在书店上找不到。偶英文不太好。不想看原版。有没有中文版的To:浩子。
这个我知道。不过看源代码太累了。有没有介绍的书。上手快一点。
你可以看一下他的类结构图,对你有帮助的
在看duwamish7的过程中碰到这个函数了。请大家说说
我理解不这个函数。谁能说说。一样有分的
里面的程序代码就是应用层或中间层
最后的数据储存，比如储存过程之类的称为数据层（也可能被包含在第二层）比如winformform 界面自己是表示层
里面的buttin_click 这样的子程称为应用层
数据储存层就是你对数据库的操作
有两遍文章是讲一个.Net的系统的开发。
它采取是三层以上的结构。
看了后对你肯定有启发。
[email protected]
因为SqlDataAdapter从数据库中选择出来的数据集的名称都是"table","table1",
"Table2"等等，需要把它应设到实际的数据集表上，
具体为"Table"对应到"用户信息"的话，
就是dsCommand.TableMappings.Add("Table", "用户信息");
其他的以此类推，
呵呵
但是用户信息是一个表吗？
那个表又有什么要求。我现在正在糊涂中
不好意思阿
n-tier develop use ASP.NET
数据服务层:(并非指底层的数据库)是建立在底层数据库的基础上(其中包括数据库中的表,视力和存储过程).是对数据库基本表所对应的表类的封装,各类完全独立,只完成本类的相关属性和事件处理(属性:对应数据表或视图中的字段;事件:对应存储过程).封装达到可以封装所有数据库中表,视图与存储过程所提供的所有信息与功能,以准备更好的为商务服务层提供服务.
商务服务层:建立在数据服务层的基础上,以商务逻辑为主线,建立与商务逻辑相关的类.本层主要针对商务逻辑进行类的划分,或者说是根据表示层的需要划分表示层每一个主要对象所对应的底层的类.(此层的类不是独立的,每一个类中都包含有与另一个类相关联的接口<方法或属性>,以实现商务逻辑化)本层在开发的过程中注重的中是商务逻辑的底层实现,对数据库根本不用过问,因为数据服务层的类已经封装好了对数据库的所有操作,只要在本层调用相应的数据服务层的类去完成相关的功能就好.以商务逻辑划分并封装好所有的类后,进而为表示层服务.
表示层(即用户接口):是指GUI的界面.或Windows开发的界面或者是Web界面.由于.NET开发把表层与底层分开,所以底二层(数据服务和商务服务)完全可以适应于任何结构的底层开发(C/S,B/S),可移植性强.三层结构的优点:便于复用,便于移植和维护....如果有耐心的话(有些书不太好看):清华一本ASP.NET站点高级编程会找到有用的东西.但源码不全,只能看部分代码讲解.本书三层开发是建立在数据库的存储过程和视图上的,数据库不好不行.
其实搞三层开发对数据库的要求并不高,我不是专业搞与数据库密切相关的产业的(比如银行一类的公司),所以,数据库的标准是够用就行.
现在市面上的书,几乎都可以讲到关于存储过程一类的问题,这是数据库层上的基本问题,并没有什么复杂的.问题不在这儿,在于你缺少开发经验.给你几点建意吧:
很多人用数据库就是使用SQL语句,用ADO,ADO.NET开发程序的人好多都是直接在商务服务层上写一些直接读取数据库的代码,也许这样很快,但维护的时间和精力是惊人的.我曾经是ASP程序员,要知道,直接用SQL调用数据库在调试的时候带来N多的麻烦.其实很多相同功能的语句我们在不厌其烦的复制再复制,调试的时候精力往往用在了复制语句时哪个字段忘改了,哪个表忘改了,而不是真正的实现思路上,成为体力劳动.出力还见不到效果.
所以,基于ADO.NET的学习,在基础上学好对象与调用方式后,把如何调用存储过程的部分研究一下,搞清楚.然后,把需要的SQL语句封装到存储过程中,在SQL后台直接调用.这样,不用说是三层开发,就是传统的二层开发在维护和结构上都要好于直接调SQL的方式.讲解存储过程的书很多,也算是SQL的基础部分,不难找.与这部分相关的有触发器,约束,事务处理.这些应该密切结合起来使用,可以省去很多在数据的处理上曾经需要在商务服务层写代码时处理的细节.然后,把多个表灵活组合,建立一个商务层需要的逻辑类所对应的视图.用一个存储过程返回所有视图的记录,使商务服务层的代码重点放在逻辑关系上,而不是数据类型的处理和判断转换上(打个比方,比如说,数据库里有两个表,分别是用户信息和电脑信息,用户信息中性别这个字段为'0'表示男,为'1'表示女.大部分开发模式是把信息读到客户端,在代码中判断,为'0'显示'男',为'1'显示女.你就可以利用视图把用户信息自动转换成客户需要的信息,在视图中把用户信息表的信息导入并同时把性别字段自动根据逻辑转换成'男','女'.这样,客户端的代码读出的结果直接应用勿需转换.另一个例子,可能表示图的一个界面中显示了一台电脑的所有信息并且显示了与这台电脑使用者的相关信息.传统方法也是用一个已经处理SQL语句调用结果,或干脆用两个SQL查询,然后在客户端代码进行逻辑判断,以把两种表的信息进行匹配.你依旧可以在数据库中利用视图把两个表的信息导入一张视图,并根据要求进行互联,此时用一存储过程返回所有视图中的记录,当客户端调用存储过程时,它所需要的所有信息都已经体现在各个字段中,只需要绑定即可.)
这是由三层开发所引发出的不同于传统开发的编程模式,要充分利用数据库所带来的好处.而且分层很清楚,便于移植和调试.
说到数据库,到是建意你去看一些关于数据库原理方面的书,因为存储过程还有触发器以及约束等等数据库特性很容易上手,只要查资料就可以.但数据库的设计是否合理,是否可以为以后的工程所复用,是一门学问,是自己的学问.需要有数据库原理的支持.我看过一本讲数据库原理基础的书,感兴趣的话,可以一看"数据库系统基础教程"--电子工业出版社.这本书是斯坦福大学的讲议改编的,出版有几年了,但绝对是经典.当然了,是我自己的看法.不是很贵,值得一试.在海图最北面新开的一家"视点科技图书"里有卖.那里面原理的书好多.我喜欢.其实写出个东西让它跑起来挺容易的,问题是让它有复用性,这就是经典的开发与普通开发的区别.我们可以常联系,以共勉共进.祝好运!
是不是这样：表示层不说了，数据库层的封装本身表的操作，而表示层是用户的界面显示，而商务逻辑层对应表示层的每个界面然后通过调用数据层的操作完成功能。可是对于表间的关联关系的操作不是还需要视图吗？这样对于数据库的操作还是直接由商务层来选择数据了。（是不是商务层的对表的直接操作只限于选择呢？）
能不能也给我个例子研究一下，先谢谢了。
[email protected]