请问如何在逻辑层使用FileUpload的SaveAs 方法呀?

问题描述

请问如何在逻辑层使用SaveAs方法呀?

解决方案

解决方案二:
我在表现层是这么写的if(myFile.HasFile){StudentShowSystemup=newStudentShowSystem();//创建对象引用if(up.SaveShow(myFile)){Response.Write("上传成功");}else{}逻辑层:publicboolSaveShow(FileUploadmyFile)//上传作品{stringstrFileName=myFile.FileName;//或取上传文件的.文件名stringstrFileExt=System.IO.Path.GetExtension(strFileName);//获取文件的扩展名doubleFileSize=myFile.PostedFile.ContentLength;//获取上传文件的大小if(strFileExt.ToLower()=="jpg"){if(CheckSize(FileSize)){//从Config中读取文件的上传路径stringstrFileUploadPath=ConfigurationManager.AppSettings["FileUploadPath"].ToString();//组和成物理路径stringstrFileNewName=DateTime.Now.ToString("yyyyMMddhhmmss")+strFileExt;stringstrFilePhysicalPath=Server.MapPath(strFileUploadPath+strFileNewName);myFile.SaveAs(strFilePhysicalPath);returntrue;}else{returnfalse;}}else{returnfalse;}}我在单步调试的时候if(up.SaveShow(myFile))到这句的时候.没有到SaveShow方法,直接跳过去了.这是为什么?我上面写的对吗?
解决方案三:
顶一下~~~~~~~~~
解决方案四:
strFileExt.ToLower()=="jpg"改成strFileExt.ToLower()==".jpg"
解决方案五:
怎么会在逻辑层看到控件的方法呢如果非要这么做就在逻辑层的类中导入WebControl命名空间然后在方法的参数中接受一个FileUpload控件,把控件的对象传进来就行了
解决方案六:
思路不对

时间: 2024-11-08 18:10:25

请问如何在逻辑层使用FileUpload的SaveAs 方法呀?的相关文章

ASP.NET2.0数据操作之创建业务逻辑层

asp.net|创建|数据 导言 本教程的第一节所描述的数据访问层(Data Access Layer,以下简称为DAL)已经清晰地将表示逻辑与数据访问逻辑区分开了.不过,即使DAL将数据访问的细节从表示层中分离出来了,可它却不能处理任何的业务规则.比如说,我们可能不希望产品表中那些被标记为"停用"的产品的"分类编号"或"供应商编号"被更新:我们还可能需要应用一些资历规则,比如说我们都不希望被比自己的资历还要浅的人管理.另外一个比较常见的情况就是

《解剖PetShop》系列之五:PetShop之业务逻辑层设计

业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,我们也将业务逻辑层称为领域层.例如Martin Fowler在<Patterns of Enterprise Application Architecture>一书中,将整个架构分为三个主要的层:表示层.领域层和数据源层.作为领域驱动设计的先驱Eric Evans

ASP.NET 2.0数据操作之创建业务逻辑层

导言 本教程的第一节所描述的数据访问层(Data Access Layer,以下简称为DAL)已经清晰地将表示逻辑与数据访问逻辑区分开了.不过,即使DAL将数据访问的细节从表示层中分离出来了,可它却不能处理任何的业务规则.比如说,我们可能不希望产品表中那些被标记为"停用"的产品的"分类编号"或"供应商编号"被更新:我们还可能需要应用一些资历规则,比如说我们都不希望被比自己的资历还要浅的人管理.另外一个比较常见的情况就是授权,比如说只有那些具有特殊

基于WF与WCF构建数据逻辑层

WF是什么,许多对NET技术有了解的人能说出一点,但又说不清楚 不论你认为WF是什么,但不要与Jbpm ,Shark ,Biztalk,SharePoint 这些产品做比效,这些产品有共同的特点就是面向企业业务流程应用的产品,WF不是,WF面向的开发人员 WF是一个使用XML描述,具有IOC.AOP功能的面向流程控制的开发平台. 我从事工作流开发有8年了,学习WF已经有5年了,在博客园写关于WF的主题博客也快4年了,自从接触WF后我一直在解释WF与传统工作流之间的区别 可能是我即从事工作流开发,

基于.NET平台的分层架构实战(十)—业务逻辑层的实现

在这一篇文章中,将实现一个NGuestBook的业务逻辑层. 在实际应用 中,业务逻辑层是至关重要的,他承载着整个系统最核心的部分,也是客户最关 注的部分.这一部分的实现,通常需要技术专家和领域专家通力合作.当然,在 本文章系列的Demo中,由于业务逻辑的简单性,这里看的可能还不是很明显. 在本篇文章的业务逻辑层实现中,业务逻辑层主要承担了以下职责: 1.对不同数据访问层的封装.使得表示层可以不关心具体的数据访问层. 2.业务逻辑数据的填充与转换.如管理员口令的加密. 3.核心业 务的实现.这里

Scott Mitchell的ASP.NET 2.0数据教程之二:创建一个业务逻辑层

返回"ASP.NET 2.0数据教程目录" 导言 本教程的第一节所描述的数据访问层(Data Access Layer,以下 简称为DAL)已经清晰地将表示逻辑与数据访问逻辑区分开了.不过,即使DAL将 数据访问的细节从表示层中分离出来了,可它却不能处理任何的业务规则.比如 说,我们可能不希望产品表中那些被标记为"停用"的产品的" 分类编号"或"供应商编号"被更新:我们还可能需要应用一些 资历规则,比如说我们都不希望被比自己的

架构设计-业务逻辑层简述

    业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创建.    业务逻辑层包含领域对象模型,领域实体,业务规则,验证规则,业务流程.1:领域对象模型为系统结构描述,包含实体功能描述,实体之间的关系.领域模型处于天生的复杂性:2:领域实体:业务层是一些操作业务对象(BO)的处理.业务对象包含数据和行为,是一个完整的业务对象.其不同于上节架构设计

java-数据访问层和业务逻辑层为什么要定义接口?

问题描述 数据访问层和业务逻辑层为什么要定义接口? 数据访问层可能会操作不同的数据库,可是业务逻辑层我感觉没必要吧,不管从哪个数据库都是一种逻辑判断吧?我感觉没必要写两个实现类 解决方案 首先,面向接口编程是一种常用的编程规范,使用接口有很多好处,例如便于扩展和代码维护等. 其次,DAO层使用接口,可能不同的数据库访问有不同的实现方法,这个用接口可能相对好理解一下: 而业务逻辑层用接口,是为了便于系统维护和扩展,万一哪一天整个业务流程变化了呢,那时我们只要重新一种实现,然后配置该类型的引用就可以

三层逻辑设计中逻辑层的输出问题

问题描述 逻辑层自表现层接受了用户的输入,经过逻辑层的处理以及从数据层取出来相应的数据,之后要输出给用户,那么应该如何做,直接newFrame()么?具体的说,逻辑层的类应该依赖表现层的类么?必须使用委托模式么? 解决方案 解决方案二:逻辑层的类不应该应该依赖表现层逻辑层是被表示层掉用数据显示处理应该由表示层处理