ASP.NET 2.0 和 ASP.NET 1.1 相比多了很多新东西.
如 数据源控件,泛型,成员管理 等,
拿数据源控件来说吧..
省去了麻烦的数据绑定过程,
代码当然也少了很多..
但近日在做一个网站项目,
用 ASP.NET 2.0 开发.
我是个普通程序员,
只负责编码,
从前台逻辑到后台数据层.
网站架构是由架构师设计好的,
大体是典型的.NET N 层架构,
缓存没加,架构师说先不考虑性能,
安全部分没处理,架构师说先不考虑安全,
当时还说不要使用泛型,
后来经过大家一顿理论总算是加上了,
数据层使用了 spring.net(nhibernate).
的确,不得不说数据层省了很多事.
private void UpdateA(A a)
{
HibernateTemplate.Update(a);
}
但在实际开发中,
却碰到了很多不太顺手的地方.
说个比较显而易见的吧,
架构师要求在构造实体类时,
将一些存在业务关系的实体结合在一起
(这也是nhibernate的一大特点).
然后通过操作主实体去更新其子实体,
也就是说,对于前台来讲,
子实体是不可直接操作的.
// 子实体类
public class B
{
private int b1;
private int b2;
...
public ...
}
...
// 主实体类
public class A
{
private int a1;
private B B;
private IList <C> clist;
...
public ...
}
这就造成前台操作有很多不便,
数据绑定:
--------------------------------------
以前的简单绑定根本没法适应现在的数据结构.
以前: Eval( "b1 ")
现在: DataBinder.Eval(Container.DataItem, "B.b1 ")
数据更新:
--------------------------------------
如果把实体类定义成和表结构相同的话(不包含业务逻辑的),
数据更新用数据源控件可以自动完成,
但初于现在这种数据结构,
必须手动完成才可以.
如 ObjectDataSource1 绑定更新方法 void UpdateA(A a);
(这个项目服务接口提供的都是这种通过实体类删,改的方法,用架构师的说法是:面向对象设计)
我的前台处理是在 ObjectDataSource 更新前拦截到该实体类实例,
并填充其子实体类.
protected void ObjectDataSource1_Updating(object sender, ObjectDataSourceMethodEventArgs e)
{
A a = e.InputParameters[ "a "] as A;
// 省略查找模板控件和获得其值过程
// .FindControl( "xxx ")
a.B = new B();
a.B.b1 = xxx.Value;
...
}
这样的更新操作还算是简单的,
想想要是对其 IList <C> 的增,删,改处理又该如何呢?!
而且,后台的更新操作都是针对整个实体类的,
这就要求,
传到后台的实例必须保证没有修改的数据项和数据库中的数据一致.
后台操作是简单了,可前台操作却麻烦的要命..
对此,架构师说要不就不使用 数据源控件.
(当时我差点吐血,
没有泛型,没有数据源控件..
那还要ASP.NET2.0干啥?
我们用 ASP.NET1.1 吧,
那样我还能安心点.)
说了一大堆,
不知道大家有没有了解我所说的,
碰到的问题还很多,
这只是一些对我来说比较 "重要 "的.
呵..
写的太长了,
怕大家没耐心看到这..
其实项目到这个份上,
我也改变不了什么,
安心编码是最好的,
我只是想知道,
spring.net 这种数据层实现是否适合 ASP.NET 2.0 ??
这种架构设计(实体类按业务逻辑组合)是否适合 ASP.NET 2.0 ??
还是我技不如人,没能搞懂 ASP.NET 2.0 应用??
------解决方案--------------------------------------------------------
你们架构师是垃圾
什么叫架构，就是根据实际需求选择最合适的程序结构。
不考虑安全、不考虑性能，就像盖房子不考虑住户舒适度，也不考虑结构稳定性一样，用盖别墅的套路来盖摩天大楼，行得通么？