Comparison between MOON. ORM and other types of ORM, and why do I write this architecture?

 

Moon's path to simplicity

1. High Performance (this framework uses a pure ADO. NET Framework to avoid performance loss caused by Linq and reflection );

2. ease of use (simple configuration, SMART awareness, and assistance from code generators, and SQL (self-performance optimization ));

3. Multi-Database Support (self-amplified if needed, the same way to join the team development (contact: qsmy_qin@163.com ))

4. Powerful syntax sugar query function

5. Supports multiple data sources. You can operate multiple databases in the same project at the same time.

6..net framework 2.0 native support. 3.5 is required for the Entity framework and the linq-based architecture.

 

 

1. I don't know how the performance of the Entity Framework is today, but 4.0 of tests are sufficient to see

Http://www.cnblogs.com/humble/archive/2011/05/19/2051053.html

This is also one of the reasons for Project extension in my previous company. At that time, Moon. ORM or version 1.0 was named after Qin. Data.

I am not talking about the Entity Framework, at least it made us fall into a swamp at that time, and performance is sometimes the key to the project.

 

2. For nhib.pdf, it is indeed good, but it is uncertain complicated. It may be easy to use and can be used as a comparison between Moon and it.

3.

People who use iBATIS know that every time you want to query a bunch of configurations, you need to write a bunch of configurations ....... 

4. I don't want to talk about other types of projects. Because there is no silver bullet in the project, it is best to suit the environment.