开发者

C# Active Record Implementations

开发者 https://www.devze.com 2023-02-22 22:59 出处:网络
I stumbled across Castle Active Record a few weeks ago and thought that it looked like an interesting solution to the laborious CRUD tasks associated with data driven applications. It seems pretty mat

I stumbled across Castle Active Record a few weeks ago and thought that it looked like an interesting solution to the laborious CRUD tasks associated with data driven applications. It seems pretty mature now and am considering using it开发者_开发百科 for the data layer of an application I am developing, but I was wondering:

  1. How well it scales? (i.e. does the extra layer over NHibernate scale well)
  2. What are its biggest limitations that will cause frustration once you are too far into development to change direction easily?
  3. Is using straight NHibernate without the Active Record layer a better long term option?


Personally, I think that Active Record pattern itself and the Castle's baby definitely have some advantages, like:

  • simplified configuration
  • the AR pattern - 'entity is independent'. Sometimes it just it's the project more that anything else.
  • you can start developing and using AR really quickly in your project. Just define proper mappings, add some config and you can already do some basic stuff with entities. That part seems faster than pure nh for me.
  • SessionScope + TransactionScope classes that are in AR are there for you already. This is something you will have to write yourself for nh if you have to e.g. support transaction inheritance.
  • all Castle projects just works beautiful together. AR + Facilities + Windsor = very powerful stack.
  • there's new version of AR (finally!) that works on top of NH 3.0.

But there are also some disadvantages:

  • the myth of overhead. I feel it's not something I can define, but it's just that feeling that all this session management, wrappers etc. just have to cost something. But I think in reality it's quite elusive.
  • if you need to do something custom you just HAVE to touch nhibernate guts. It seems to be pretty complicated with AR.
  • no 2nd cache support
  • AR mappings are not POCOs. Might be an issue when serializing through WCF or just sending between different layers. It's not the case with NH.
  • AR is just not the best way to force OO approach for repositories/dao classes. But that's nothing new because it's pure consequence of AR pattern - your object knows how to save or delete himself. But it's becoming a pain when your project grows a little bigger.

So in the end, it's a great framework to use with simple or medium complex projects. It's good for asp.net/winforms, doesn't matter. With pure NH, you will definitely have to code much more to make similiar application. But if you'll do it, you will be much happier. Because you'll be able to control everything.

As always, it's all up to your preference or project. For small, quick projects - AR is the way, for medium - I would say NH is THE way!

p.s. oh, by the way, AR makes exactly the same queries, so it's like using nh to talk to db. NH scales and so does castle. Just avoid 'n+1' problem and think about laziness and you should be good;P

p.s. listen to Mauricio Scheffer, he really knows what he' writing about.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号