采用ORM框架,必须迁就数据库的设计吧?

本人于CSDN发表了一个帖子,宣布一磨蹭强大的ORM工具–PDF.NET集成开发工具
,有只对象caozhy提出了异常中肯的题目,我本着他的问题举行了回,现在以为他的题材颇有深度和代表性,现在打点在此供大家讨论。

================caozhy的题目是========================:

由技术之角度看,lz的想法是好的。

然而自从商业的角度看,存在有题材:

(1)开发者能够免可知收获技术支持的承保?培训谁来举行?
(2)后继的保障谁来做?BUG修复?
(3)ORM的框架众多,lz的制品优势在何?定位简单还是功能强大?如果是概括,lz的立即套语法/函数还是稍微发复杂。
(4)对于一款面向.NET的ORM框架,如果未般配 IQueryable
接口是平等栽相当深之不满。这意味,我还得使面向数据库架构的语法来控制业务逻辑。
(5)支持广大数据库固然好好,但是lz如何处理数据库方言问题?对于绝大多数低端用户来说,能怪好特别方便地拍卖好MSSQL就坏不错了。对高端用户来说,支持多数据库并无是绝无仅有的内需,他们待安静、高效和高伸缩性和可扩展性。说到底,还是定位问题。目前之Entity框架就召开轻量,它不管和IDE的构成,还是ORM以及跟言语的组成,做的都分外好。比如ModelFirst、CodeFirst或者因表建模,而lz的方案看上去要在数据库暨模型代码之间定义两不行,而且尚未好好以数据库架构和模型分离。
(6)ORM本身的错综复杂没有因此了的口蛮麻烦想象。lz因为既是使用者,又是开发者,所以有思考一贯——如果本身100%凡这框架的编者,或者自己对框架的保有实现完全掌握,我竟会设想以好的框架代替通用的ORM。但是,如果我莫是框架的设计者,没有读过一切源代码(即使你提供代码,我出无产生能力去念还是个问题),那么你假想的“轻量”、“简单”都是勿设有的。简单的事物不是绝对意义及之概括,而是可以尽借鉴现有的学问和针对性她的汇报有尽的把。
(7)有没有出能说服我利用其恐怕连无是一个简短的事例,查询几修记下,事实上对比所有同类产品,实现这样的功力都异常易。我说几长达EF的题材,不亮堂您的制品是否缓解:
 – 对于泛型实体的支撑,假而自己如果统筹一个考系统:

C# code
class Questions where T : QuestionBase { }
{
public List Questions { get; set; }
}
class QuestionBase { }
class SingleSelectionQuestin : QuestionBase
{
public string Description { get; set; }
public List Options { get; set; }
public string Selected { get; set; }
}
class MultiSelectionQuestin : QuestionBase
{
public string Description { get; set; }
public List Options { get; set; }
public List Selected { get; set; }
}
class BriefAnswerQuestin : QuestionBase
{
public string Description { get; set; }
public string Answer { get; set; }
}

这种情景下,使用时本的Entity框架,我不能不迁就数据库的设计,这即是时ORM缺陷的原委。

  • 对于多实例可扩展性的支持
    遵照自己的数据库部署到 SQL Server Azure 上,我之程序托管在Windows Azure

    WebRole里面。可能自己来10只WebRole,并发访问数据库,数据一致性怎么保?

    非常复杂的数据库关系和搭,比如多只外键,级联查询,唯一性约束,参照完整性约束。比如从定义函数和SQL类型等等

    数迁移问题,说实话,数据迁移是几乎所有人数还关注的基本问题,而且是权ORM好坏的重中之重标准。对于一个渐进添加功能的Web程序,程序的升迁,同时保证原有的数额平滑地搬迁至新的数据库中凡是十分重大的工作。对于Rails的ActiveRecord,就做的不行好。迁移几乎自动进行,甚至还得反向的动迁。
    每当闭源产品(我是说.NET)上支出,这漫长路十分艰苦,很多好挺之出品相继倒下了,lz要慎重。

 

===============我之回==========================:

非常感谢 caozhy 的建议及题材,下面逐一回应如下:
(1)开发者能够无克获得技术支持的管?培训谁来做?
–对于正式用户(也不怕是消费10片钱请源码的用户)提供在线支持,培训资料在社区发生连带的博客、论坛文章;
(2)后继的掩护谁来举行?BUG修复?
–由于PDF.NET框架是当实质上商业产品被之动,所以保护一直在进行,功能扩展及Bug修复一直于进展着;
(3)ORM的框架众多,lz的活优势在哪里?定位简单还是功能强大?如果是概括,lz的即套语法/函数还是小发复杂。
–框架的基本点特点是拥有iBatis的SQL-MAP功能和支持.NET
2.0底面向对象方式的询问表达式OQL,定位是粗略好用,在采用
SQL-MAP的当儿,只需要写好SQL语句,有代码工具自动生成DAL代码;在运OQL的时,大部分且是单表简单的CRUD操作(
复杂的SQL语句都因此SQL-MAP实现了),OQL.From(entity).Select(entity.Property,…).Where(entity.Property)
这样的语法还是非常粗略的,
万分接近SQL的写法,如果产生比较复杂的规则,可能表达式构造稍显得复杂(但复杂的SQL都用SQL-MAP去落实了),Update、Insert、Delete操作
最好简便,不用多说了;
(4)对于一款面向.NET的ORM框架,如果非匹配
IQueryable
接口是同一种相当深的缺憾。这意味着,我还非得以面向数据库架构的语法来决定业务逻辑。
–由于历史原因,框架最初定位于支持.NET2.0,IQueryable 是.NET
3.0以后才支撑,目前在考虑框架直接支持LINQ;
(5)支持广大数据库固然非常好,但是lz如何处理数据库方言问题?对于大部分低端用户来说,能挺好慌轻便地处理好MSSQL就怪科学了。
–正因生不同数据库的白问题,所以框架下SQL-MAP技术,将那些需要快速履之、数据库特性的SQL单独写到布置文件被,当得切换数据库的时光,
只替换这个SQL配置文件即可(SQL-MAP配置文件);
“比如ModelFirst、CodeFirst或者因表建模…”
–框架提供了于数据库来生成实体类的家伙,但为允许你先ModelFirst、CodeFirst,我之过剩演示(比如示例操作OQL的有些)都是直开立实体类,
没有规划数据表的,如果用手工方式,你可于定义要持久化哪些性和怎样持久化;
(6)ORM本身的错综复杂没有因此了之总人口颇麻烦想象…但是,如果自己莫是框架的设计者…那么您假想的“轻量”、“简单”都是未存在的。
莫绝认可你说的“不是设计者”就无法肯定框架是“轻量、简单”的这个看法,“轻量”可以自软件之文件大小、对环境、系统的依赖程度相当方面来确认;
“简单”可以于实际用过程体会出,已经有许多就此了要押了框架的恋人肯定的游说“确实略”了,例如参看这首文章的还原:
http://www.cnblogs.com/bluedoctor/archive/2011/04/01/2001887.html

匪应用反射的实业类方案
http://www.cnblogs.com/bluedoctor/archive/2010/02/08/1665795.html

7)有没有发生能说服我动用其恐怕连无是一个简易的例子…
–首先,框架不是个人闭门造车的结果,而是实实在在的档次用之结果,比如最近我们举行的银行资金分析体系,这样的系错综复杂和数据量自然不用怀疑的;
对于你的“对于泛型实体的支撑”的题目,我眷恋不是当泛型类本身支持实业的题材,而是QuestionBase具体贯彻类似如何支持实体类的问题,你可先CodeFirst,
先筹“领域模型”(我当你被的事例不再是一个简的实体类了,而是一个天地模型),再手工对实业类进行持久化,例如持久化SingleSelectionQuestin:

率先,建议您拿 QuestionBase 定义为接口,

C# code

interface QuestionBase
{
  public ID{get;set;}
}

下一场,修改只是选实体类:

C# code

class SingleSelectionQuestin : QuestionBase,EntityBase
{
    public string Description { 
    get{return getProperty<string>("Description");} 
    set{getProperty<string>("Description",value,50);}//假设Description 字段长度为50
    }

    public string Tb_Options { 
    get{return getProperty<string>("OptionList");} 
    private set{getProperty<string>("OptionList",value,500);}//假设OptionList 字段长度为500
    }

    public List<string> Options { //假设Options 的结果以逗号分隔的字符串的形式,存在与数据库表字段OptionList 中
    get{this.Tb_Options.split(',').ToList();} 
    set{this.Tb_Options= string.join(value.ToArray(),",");} 
    }

    public string Selected { 
    get{return getProperty<string>("Selected");} 
    set{getProperty<string>("Selected",value,50);}//假设Selected 字段长度为50
    }

    public int ID { 
    get{return getProperty<int>("ID");} 
    set{getProperty<int>("ID",value);}
    }


    public SingleSelectionQuestin()
    {
         TableName = "TB_SingleSelectionQuestin";//表名称

            //IdentityName = "标识字段名";
    IdentityName="ID";

            //PrimaryKeys.Add("主键字段名");
    PrimaryKeys.Add("ID");

    }

      protected override void SetFieldNames()
      {
           PropertyNames = new string[] { "ID","Description","Selected","OptionList"};
      }


}

末尾,在公要之地方来得到QuestionBase类的实例,例如:

C# code

QuestionBase question= QuestionFactory.GetQuestionInstance();//假设有这一个问题类工厂
 question.ID=100;//给问题ID赋值
 EntityBase entity=question as EntityBase;//实体类基类
 EntityQuery<EntityBase>.Fill(entity);//填充该实体
 //下面对实体类进行其它操作
 EntityQuery<EntityBase>.Instance.Update(entity);//保存修改

马上段代码可以停放你待的地方;

动这种CodeFirst的法子,最后根据需要来持久化实体类,就未待迁就数据库表的计划了。

(8)- 对于多实例可扩展性的支持
–并发访问数据库,数据一致性的渴求,对于ORM来说是休是讲求最好胜了来?这些应是数据库或者特别的工作层去做的作业;
(9)-
非常复杂的数据库关系及搭,比如多个外键,级联查询,唯一性约束,参照完整性约束。比如从定义函数和SQL类型等等
–PDF.NET的实业类本着从简的规则,实体类没有引入复杂关系之概念,遇到这些复杂的查询,可以用SQL-MAP功能,它好将DataReader的结果读入实体类吃;
(10)-
数据迁移问题,说实话,数据迁移是几所有人还关心的中心问题,而且是权ORM好坏之要标准。
–下面是场面是否以及你的斯题目类似?
俺们出一个体系,有部分基础数据要由咱的SQLSERVER库远程同步到客户的系统中,而客户之系以的数据库目前发出SQLSERVER,PostgreSQL,这样的数码并
算不到底类似你说之多少迁移呢?请参见我下的篇章:
唯不换的便是一直在变”–“数据”的雍容华贵“变身术” 
http://www.cnblogs.com/bluedoctor/archive/2011/02/23/1962218.html

于系SQL Server的实现中,有关数据的导入和导出,采用实体类非常好的荫了多少的异样,比如目标表和源表字段名称以及数目不相同的题材。

流淌:有关PDF.NET数据访问框架的问题,请参考官网地址

http://www.pwmis.com/sqlmap

还是我的博客相关文章。

 

相关文章