关于ashx文件怎么写合理
0
悬赏园豆：30
[已解决问题]
解决于 2010-08-07 19:22
纯HTML+AJAX+JQUERY+JSON的开发，想必大家都熟悉不过了。但一个稍复杂少少的web page可能涉及到多次数据读写操作，如下拉列表的联动，数据的展示等。我想说的问题是。
1.究竟是一个功能对应一个ashx还是一个页面对应一个ashx呢？前者导致ashx很多，而后者给我感觉怪怪的，请大家发表一下自己的处理方式。
2.大家在处理跨页访问获得JSON数据的处理方式是什么？典型的场景是，A页面传入QueryString到B页面，而B页面要通过另一个ashx文件去拿数据，B页面必然要把A页面的QueryString抛给ashx，我的做法是自己写一个处理地址去得出具体的QueryString之组装再抛，一般都有这些JS现成插件，不过总觉得有点别扭，不知道大家又有什么好的做法？
最佳答案
0
就一个ashx，通过对传入参数的解析，调用不同的功能，比如给每个功能一个字符串ID，然后在服务器收到后通过该ID选择不同的处理函数或者类，选择处理函数或类的时候，就可以使用IOC来消除switch语句。
收获园豆：30
兄台意思是一个项目一个ashx文件还是一个页面对应一个ashx文件？
一个项目就一个，不是一个页面.也不能完全说是一个项目，就是同一类相关功能就一个ashx，别的项目也可以调用。
如果项目稍大，这样的ASH可能会变得很庞大，不是嘛？
当然不是，ashx相当于设计模式中的Facade.在于把你后面的逻辑通过一个统一的界面提供给客户端。
哥们，一言道破我的顾虑啊，希望和你交个朋友。
其他回答(3)
0
习惯一个表对应一个...关于一个表的逻辑全写进去，根参数决定执行哪个功能，就是哪个函数，然后返回相应的数据。
这个要看你的了。
问题关键是，没可能只出现单表操作。。
@桀骜的灵魂:就像实体类和三层中的业务逻辑，默认只是单表，当然你也可以建立一个综合的。
BLL和实体类，甚至说DAL肯定要符合单一原则了，但我说的是UI层，UI是组装这些单元的地方，UI中的一个功能单元可能要用到多个BLL来实现对外需求。而这里的ashx在我看来是一个UI组件，我所想的UI不单单是HTML、JS、服务器控件，还有其特有的UI逻辑，怎么展示，展示什么数据，传递什么数据，根据需求而定，当然单一情况是有的，但在企业开发中基本这种情况可以忽略。
@桀骜的灵魂:不用这么纠结，ashx就像原本的aspx.cs，只不过你换了另一种模式，至于怎么来组合，情况可以很多种，这没有要求，也没有规定，选一个适合你的。
0
你可以将某个功能模块的ajax相关操作放到一个ashx文件中，这样便于管理。 ajax请求该资源文件时候传入方法名，园子里有人贴过相关代码，如下
public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text/plain";
context.Response.Buffer = true;
context.Response.ExpiresAbsolute = DateTime.Now.AddDays(-1);
context.Response.AddHeader("pragma", "no-cache");
context.Response.AddHeader("cache-control", "");
context.Response.CacheControl = "no-cache";
try
{
if (HttpContext.Current.Request["cmd"] != null)
{
string cmd = HttpContext.Current.Request["cmd"];
var method = this.GetType().GetMethod(cmd);
if (method != null)
{
method.Invoke(this, new object[] { context });
}
}
}
catch (Exception ex)
{
}
}
public void Add(HttpContext context)
{
//相关业务
}
public bool IsReusable
{
get
{
return false;
}
}
这里应用反射，直接把耦合降对最低，牺牲了一点性能，把条件判断全部灭掉了。不得不佩服。
0
这篇贴子让我明白了不少道理啊