SQL Server采纳O科雷傲M框架,必须迁就数据库的安排啊?

自个儿在CSDN揭橥了一个帖子,发布一款强大的O安德拉M工具–PDF.NET集成开发工具
,有个朋友caozhy指出了尤其尖锐的题材,小编对他的标题做了回复,未来觉得她的难题很有深度和代表性,今后整治在此间供咱们商讨。

================caozhy的题材是========================:

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

只是从商业的角度看,存在有的题目:

(1)开发者能或不能够得到技术协理的担保?培训什么人来做?
(2)后继的掩护什么人来做?BUG修复?
(3)OXC60M的框架众多,lz的出品优势在何地?定位简单依然功用强大?如若是简单,lz的那套语法/函数依然略显复杂。
(4)对于一款面向.NET的O途观M框架,如果不般配 IQueryable
接口是一种卓殊大的不满。那表示,小编还非得利用面向数据库架构的语法来控制业务逻辑。
(5)扶助广大数据库尽管很好,可是lz如何处理数据库方言难点?对于多数低端用户来说,能很好很便捷地处理好MSSQL就很科学了。对高端用户来说,帮衬多数据库并不是绝无仅有的必要,他们要求稳定、高效以及高伸缩性和可伸张性。说到底,如故定位难题。最近的Entity框架就做轻量,它不管和IDE的组成,照旧O昂科拉M以及和言语的结缘,做的都很好。比如ModelFirst、CodeFirst只怕根据表建模,而lz的方案看上去须求在数据库和模型代码之间定义五回,而且尚未很好将数据库架构和模型分离。
(6)OLANDM自己的扑朔迷离没有用过的人很难想象。lz因为既是使用者,又是开发者,所以有思考一向——固然本身百分之百是其一框架的编者,恐怕本人对框架的全数完成完全控制,作者依旧会考虑接纳本身的框架代替通用的OHavalM。不过,即便本身不是框架的设计者,没有读书过任何源代码(就算你提供代码,作者有没有力量去读依旧个难点),那么你假想的“轻量”、“简单”都以不设有的。容易的东西不是相对意义上的简要,而是可以尽管借鉴现有的文化以及对它的反映有丰盛的把握。
(7)有没有可以说服作者利用它只怕并不是3个回顾的例证,查询几条记下,事实上相比较全数同类产品,达成这样的效率都很不难。作者说几条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框架,小编必须迁就数据库的陈设性,那就是现阶段O奥迪Q7M缺陷的原由。

  • 对于多实例可扩张性的帮忙
    比如说自身的数据库布置到 SQL Server Azure 上,作者的主次托管在Windows Azure

    WebRole里面。大概小编有十个WebRole,并发访问数据库,数据一致性怎么确保?

    万分复杂的数据库关系和架构,比如四个外键,级联查询,唯一性约束,参照完整性约束。比如自定义函数和SQL类型等等

    数量迁移难题,说实话,数据迁移是大约全体人都关切的着力难点,而且是衡量O冠道M好坏的重点标准。对于1个渐进添加功效的Web程序,程序的晋级,同时确保原有的多少平滑地搬迁到新的数据Curry面是不行重大的事体。对于Rails的ActiveRecord,就做的很好。迁移大致自动举行,甚至还能反向的迁徙。
    在闭源产品(作者是说.NET)上付出,这条路很劳顿,很多很大的制品相继倒下了,lz要慎重。

 

===============作者的回复==========================:

非凡谢谢 caozhy 的提出和难点,下边逐一遍应如下:
(1)开发者能否博取技术匡助的担保?培训什么人来做?
–对于规范用户(也等于花10块钱购置源码的用户)提供在线帮忙,培训资料在社区有相关的博客、论坛小说;
(2)后继的掩护哪个人来做?BUG修复?
SQL Server,–由于PDF.NET框架是在事实上商业产品中的应用,所以爱慕一贯在开展,功效扩大和Bug修复一直在展开中;
(3)O冠道M的框架众多,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的O君越M框架,假若不协作IQueryable
接口是一种拾贰分大的不满。那表示,小编还非得采纳面向数据库架构的语法来决定业务逻辑。
–由于历史原因,框架最初定位在帮衬.NET2.0,IQueryable 是.NET
3.0随后才支撑,如今正在考虑框架直接协理LINQ;
(5)协理广大数据库即使很好,可是lz如何处理数据库方言难题?对于多数低端用户来说,能很好很便利地处理好MSSQL就很科学了。
–正因为有两样数据库的白话难点,所以框架使用SQL-MAP技术,将那么些需求快速执行的、数据库本性的SQL单独写到配置文件中,当须求切换数据库的时候,
无非替换那些SQL配置文件即可(SQL-MAP配置文件);
“比如ModelFirst、CodeFirst大概根据表建模…”
–框架提供了从数据库来生成实体类的工具,但也同意你先ModelFirst、CodeFirst,笔者的众多示范(比如示例操作OQL的一些)都以一向创制实体类,
未曾规划数据表的,假诺应用手工方式,你可以自定义要持久化哪些属性以及如何持久化;
(6)O兰德酷路泽M本人的繁杂没有用过的人很难想象…可是,借使本人不是框架的设计者…那么您假想的“轻量”、“简单”都以不存在的。
不太认同你说的“不是设计者”就无法肯定框架是“轻量、不难”的这一个意见,“轻量”可以从软件的文件大小、对环境、系统的看重程度等方面来确认;
“简单”可以从实质上运用进度体会出来,已经有不可计数用过照旧看过框架的朋友肯定的说“确实简单”了,例如参看那篇作品的回复:
http://www.cnblogs.com/bluedoctor/archive/2011/04/01/2001887.html

不行使反射的实体类方案
http://www.cnblogs.com/bluedoctor/archive/2010/02/08/1665795.html

7)有没有可以说服小编利用它或许并不是3个简短的例子…
–首先,框架不是私有闭门造车的产物,而是实实在在的花色拔取的结果,比如如今大家做的银行资金分析系统,那样的系列错综复杂和数据量自然不用思疑的;
对于你的“对于泛型实体的支撑”的题材,作者想不是在泛型类本人辅助实体的难点,而是QuestionBase具体落到实处类如何扶助实体类的题材,你可以先CodeFirst,
先规划“领域模型”(小编觉着你给的事例不再是一个简便的实体类了,而是1个天地模型),再手工对实体类进行持久化,例如持久化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)- 对于多实例可扩大性的帮忙
–并发访问数据库,数据一致性的必要,对于O帕杰罗M来说是否讲求太高了些?那么些本该是数据库恐怕特其余事务层去做的事情;
(9)-
极度复杂的数据库关系和架构,比如三个外键,级联查询,唯一性约束,参照完整性约束。比如自定义函数和SQL类型等等
–PDF.NET的实体类本着从简的口径,实体类没有引入复杂关系的概念,碰到这么些复杂的查询,可以利用SQL-MAP功效,它可以将DataReader的结果读入实体类中;
(10)-
数据迁移难点,说实话,数据迁移是大概全数人都关心的主导难题,而且是衡量OENVISIONM好坏的机要标准。
–上边这一个情景是还是不是与您的那一个题材类似?
大家有多个系统,有一部分基础数据需要从我们的SQLSERAV4VEENCORE库远程同步到客户的系统中,而客户的系统使用的数据库近来有SQLSEOdysseyVEOdyssey,PostgreSQL,那样的数目同步
算不算类似你说的多寡迁移呢?请参见小编下边的小说:
唯一不变的就是一向在变”–“数据”的雍容高尚“变身术” 
http://www.cnblogs.com/bluedoctor/archive/2011/02/23/1962218.html

在系统的兑现中,有关数据的导入和导出,拔取实体类很好的遮光了数据的分歧,比如目标表和源表字段名称和数量不相同等的难点。

注:有关PDF.NET数据访问框架的难点,请参见官网地址

http://www.pwmis.com/sqlmap

依旧本身的博客相关作品。

 

相关文章