ORM框架有无必要？

12-07-31 bigmouthz

疑问：
1、ORM从未逃离数据库的影子，既然无从逃离，为何又要执著于ORM呢？

2、有些时候实现一个复杂的SQL后台查询，用程序语言（非SQL (我也走过弯路，用了被MS鼓吹的linq，以及linqtosql )）实现起来相当有难度，既然如此为何还要把复杂度为一度的问题变为二度、三度甚至N度呢

基于此，我做了以下的处理，见｛方案｝
3、这样做是不是真的减轻了开发的工作量？不好意思，并没有减轻。针对于直接用SQL访问的（JDBC或者ADO.net）相对而言是加重了。
但是把在关注点转移了业务中的逻辑实现，复杂度放在UI层与用户交互上。
如何设计你的Query, 传入参数到IQuery;
配置层XML如何去写你的SQL语句；
程序主体业务关不关注这些，程序只是关注接口（只关注IQuery）。
对于XML层部分可以写代码自动生成，复杂的SQL还是要人工干预，界面UI的复杂查询也是需要人为处理的。

4、可扩展性和引入其它大家可以参见 martin flower的企业设计模式架构

------------------------------------------------------------------------------------------------------------------
｛方案｝：
刚刚学java想找出与ms entrprise library相媲美的库，度娘告之有apache commons dbutils ，主要相中了其tobean，的确是个好东东

下面是我的思路，请大家指证（以下语法为C#，不过思路是相通的）

public abstract class absRepository<T,Key> : IRepository<T,Key> where T : class, new()
{
SQLHelper db = new SQLHelper(); // java调用apache commons dbutils， .net中用的是ms entrprise library IDataReaderEntityBuilder<TResult>.CreateBuilder(datarow);

public abstract string OwnerName { get; }//可以取自某配置获取内容
}

public interface IRepository<T, Key>
{
/// <summary>
/// 对象标识
/// </summary>
string OwnerName { get; }

IList<T> GetByCriteria<Query>(Query query);

IList<T> GetByCriteria<Query>(Query query, int pageIndex, int pageSize, out int pageCount);

int GetCount<Query>(Query query);

bool Contains(Key key);

T Get(Key key);

bool Create(T t);

bool Update(Key key, T t);

bool Remove(Key key);

Key Get(T t);

bool Equals(Key l, Key r);
}

public interface IQuery
{
/// <summary>
/// 查询编号，或者查询语句
/// </summary>
/// <returns></returns>
string getNo();

object[] getParams();
}

public interface ISortQuery : IQuery
{
string sort { get; set;}
}

[该贴被bigmouthz于2012-07-31 13:39修改过]

brighthas

2012-07-31 14:17

ORM和数据库只是基础设施，你可以考虑采用DDD和CQRS框架，进行编程。
以业务为中心，而不是以数据库或变相的数据库ORM为中心。
也就可以摆脱以前的贫血对象的问题。

bigmouthz

2012-07-31 18:15

谢谢brighthas 刚刚抽空看了一下CQRS ,

C很容易理解，我也曾在项目中用对event的publish,subscribe也就是所谓的事件总线来处理；这个应该是类似的概念。

Q也就是类似于我上述的IQuery处理，不过唯一不同的就是它是针对于可能是大的内存数据集（库）；把它放在了Service层，而不是我这里用到的IRepository层。

好的，回过头来也是我的疑问CQRS中的Q 的来源是如何生成的呢，是不是也是类似于把多SQL集成为一个LIst<T>的业务集合呢，换句话来说是不是也没有最终逃离我上述的步骤。只是更高一层的抽象了的业务处理方式。

C这块就不多讲事实上我把它理解为通过event bus调用对Service层的处理. Q这块也可以通过event bus来调用Service层，（当然可以用到cache , 在service层实现）

其实我个人认为，至于访问是CQRS也好DDD也好
我的做法是想使事情简单化，而不应拘泥于某个框架或者某类框架
只是抽象为一种思路具体的情况视项目而定

[该贴被bigmouthz于2012-07-31 18:17修改过]

brighthas

2012-08-01 09:33

2012-07-31 18:15 "@bigmouthz"的内容

Q也就是类似于我上述的IQuery处理，不过唯一不同的就是它是针对于可能是大的内存数据集（库）；把它放在了Service层，而不是我这里用到的IRepository层。 ...

CQRS 核心就是领域层和读取数据分离，CQRS其实是DDD的落地框架。

Query不一定走Repository路径，只要快就可以，越快越好，比如直接用 SQL select 直接读数据库最好，最快。

Command 部分其实可以省略，直接用应用层代替也可以，但如果项目大最好采用Command 。

类似的编码如下：可参看 http://www.jdon.com/44191

var command = new Command(...);

// 内部调用Command指定的Handle，再由Handle调用领域层代码。
commandBus.execute(command,callback);

<p class="indent">

[该贴被brighthas于2012-08-01 09:34修改过]

cuwkuhaihong

2012-08-04 10:34

ORM这个思想是必要的，但是物极必反。像hibernate就是走了ORM的极端。他忘了开发应该简洁，高效，实用，并将OO思想带入了一个令人尴尬的局面，导致人们都OO的质疑。在实际开发中只有参与业务逻辑才需真正的对象，因为要规范调用参数或接口，其他情况都不是必须使用对象的。所以我认为大家应该放开思想，不要局限于条条框框。以简洁，高效，实用为目的写程序做设计。所谓的标准也是为达此目的而立的，有悖于此的标准都将被淘汰。

suigara

2012-08-07 16:19

非常同意

DDD也好，CQRS也罢，目标是什么？
拘泥于规则反而会受到限制。

规则不会让事情变得更好，只是不让事情更糟而已（这点有时都做不到）

了解目标就可以了

Pescod

2012-08-19 10:17

涉及到业务逻辑的，需要使用OO的思想，当然需要ORM框架来配合了。
如果只是查询，当然是直接SQL更方便了。

banq

2012-09-13 16:19