监理公司管理系统 | 工程企业管理系统 | OA系统 | ERP系统 | 造价咨询管理系统 | 工程设计管理系统 | 签约案例 | 购买价格 | 在线试用 | 手机APP | 产品资料
X 关闭
进销存软件免费版

当前位置:工程项目OA系统 > 领域应用 > 免费仓库管理系统 > 进销存软件免费版

免费进销存软件是什么CRM设计方案

申请免费试用、咨询电话:400-8352-114

   


一、开发基础选用


        进销存软件免费版开发基础包括数据访问,监控跟踪,异常处理,日志记录,公共函数等东西,每个系统一般都不是从零开始做的,都有个基础架构的,有的可能功能少一些,但是数据访问是必须的,我列举一下备选的方法供大家讨论。
  1、听堂的SPL

评价:简单易用,功能也不弱,能有效提高开发效率,但是处理存储过程上还有些缺乏自动化,而且我感觉有点儿争议的是它没有返回IDataReader的接口是不是个缺陷,当然作者有自己的考虑。
  2、双鱼座的Kanas.Net

评价:双鱼的这个东西我是在好几年前CSDN的帖子里看到的,功能很全面,也不知道他让不让用,估计采用的话学习成本会提高。CSDN的那个帖子地址如下,里面有几个人对ORM的讨论

  3.ASP.NET电子商务高级编程》里凯文.霍夫曼写的.NET CMP框架

评价:可以有效减少代码数量,错误处理,检测跟踪也都集成了进去,是一个很灵活的框架,存储过程处理非常方便,而且使用了托管容器的概念,使业务层代码可以不关心数据访问层的代码。

评价:有配套的代码生成器,功能很强大,能生成好多代码,在项目里同步一下就可以更新,自动生成的CRUD操作和对存储过程的操作都考虑的很周全,数据访问默认已经支持了并发处理和多层处理,可以方便remoting的调用。内置性能计数器等处理。
  5.微软的EL
DAAB大家都很熟悉了,但是我却没怎么用过,微软的这套应用程序块使用了策略的模式,使用起来很方便,耦合性也小,但在开发效率上不如以上几个框架考虑的多感觉。

二、架构选择


       为了保证软件最终的可伸缩性,打算使用多层架构来开发。业务层代码,表示层,数据库层都可以分别运行在不同的机器上。表示层可以使用智能客户端,WEBFORM,移动工具等,业务层以remotingweb services形式发布,数据库采用ms sqlserver


         具体我是这样考虑的像需要报表,图表,以及管理的功能都做成智能客户端来实现,因为这些功能用浏览器来实现需要费很大的周折,我的意思是对使用这些功能的客户部署一个引导的小程序,也就是application browser,然后这个应用程序浏览器通过一个web服务来获取可用的功能,以及执行这些功能的程序集的位置,从一台单独的web服务器上下载程序集缓存到本地来执行客户端逻辑。这样给这些客户端发布新功能的时候可以更改这个web服务,通过这个web服务像智能客户端发布新功能,自动下载,执行。这些桌面程序执行的时候是远程创建remoting对象,然后调用这些对象的方法,而remoting对象可以驻留在另一台单独的应用程序上。
  然后大多数功能通过asp.net来实现,asp.netweb服务器也是调用remoting服务器上的对象来运行业务逻辑,然后生成通过webform来和客户进行交互。
  还需要一个移动应用程序,每个客户可以通过PDA或其它设备查看自己的客户,以及客户的手机,住址等信息,方便他们用移动工具沟通,加大销售的机会。
  基本上架构上我就是这样考虑的,当然所有的服务可以在一台机器上运行,但是也为以后扩展提供可伸缩性。

三、身份验证和授权


       因为程序本身支持多界面,所以我打算身份验证用一个web服务来执行,这样在桌面程序,asp.net,移动控件都可以调用web服务来进行身份验证并获取令牌,令牌也可以串行化并在层间传递,当然这样的话需要用到xml签名,xml加密,对客户端IP验证等一些列增强安全性的措施。

四、管理


      管理工具分为两种,一种是对业务的管理,比如修改权限,添加产品,添加客户等,这些管理功能最好是使用windows验证方式在局网内进行管理,或者是使用webform远程管理的话需要使用一些增强的安全性,比如说https等。还有一种管理是对remoting服务器的跟踪和管理,比如停止windows服务,查看对象实例化的个数等。这些管理行为想做个桌面程序来管理服务进程,使用那个那个什么singleg模式,好像叫单件模式,这样可以远程停止,启动,查看remoting的运行装款以及windows服务。最好是可以集成到微软的MMC里面

五、合理使用代码生成器,第三方控件,模块,工具


        比如说nunit,nant这类的东西最好能利用起来,懒是程序员的美德,能省事咱就省事,当然是保证安全和质量的情况下。控件方面也尽量用已经可用的控件,不自己开发。模块呢,像身份验证啦这些都是通用的,可以拷贝一些代码进来,进行测试后投入使用。代码生成器大多灵活性不够,可以使用我的wawacodepro或者其它有些支持模板的代码生成器来减少重复性代码的手工输入。

六、自动化处理,异步处理,分布式事务管理


       因为使用了多层架构,就得考虑到网络阻塞的情况,所以我们得使用一些异步处理方式以及自动化处理程序,比如说把添加的客户生成的数据先串行化成xml,然后保存在一个目录里,然后通过一个windows服务监视这个目录处理里面的XML数据并放入数据库里,使用一些重试队列来处理意外情况,如果加入重试队列2次以上就放入停止队列里面。这种方法经常用在订单处理里面,我们需要的话也可以把部分逻辑使用这个方法处理。如果到时候架构很复杂的话需要用一些分布式事务管理,来保证业务数据的完整性,这个先考虑进去。

七、自动部署和代码访问安全


     这是.NET的特性,使用了智能客户端,这些都要考虑一下,不能为了使用智能客户端而增加了部署的麻烦和降低了安全级别。

八、计数器


       这些东西要集成到管理工具里面,一般使用.NET的特有的几个计数器就可以,主要死活用性能(资源)计数器,用量计数器,频率计数器,这些在构建.net remoting对象的时候需要加进去,可以让管理工具查看某个remoting方法一分钟调用了多少次,某个remtoing对象有多少个实例,可以查看CLR运行占用的资源等

九、异常报告,事件日志,调试跟踪,负载平衡


        如果是在智能客户端上发生了异常要把异常用web服务或者电子邮件发送到异常管理人员,如果是服务器上发生了异常也要用web服务把异常报告到集成的地方,我认为web服务来报告异常是很好的,智能客户端可以加入一些在线崩溃分析的功能,报告异常的时候另外要报告一些额外的信息,比如说当前windows登陆用户名,磁盘剩余控件,进程ID等信息,便于分析人员分析鼓掌原因。

  使用事件日志是一种过时的技术,还需要人为的去查看错误记录。但是我们可以双管齐下,日志可以让系统管理员得到一些帮助。
 
  在开发阶段debug是很有用的,可以帮助开发人员分析程序为什么出错,而trace是程序正式运行后出现了问题,可以启用跟踪来查看变量的输出,用来分析程序的运行情况,这些都要考虑进去。
 
  最后负载平衡,我想要对循环法给予支持,因为只需要几行代码就可以实现。而对单点故障法暂时不用考虑,因为需要application server或者硬件的支持

十、最后是易用性问题

        为了提高用户体验,在界面设计上要多为客户考虑一些,颜色,布局,使用方便,每日提示,帮助,状态栏提示,习惯性调查,使用首选项等都要提供。

基本上就是这些吧,我明天要回乡下,参加项目的朋友先看看我的方案,给点儿意见。

 

来源:北京泛普和,北京网站建设,北京软件开发公司,免费进销存管理系统系统介绍,QQ号:2725110947  联系电话:010-51246210 ; 15699913471 

 

 

发布:2007-04-20 13:48    编辑:泛普软件 · xiaona    [打印此页]    [关闭]