Subsonic 3 VS 实体框架
有人使用过 Subsonic3 和实体框架吗？谁能告诉我它们的优缺点？ 这是我第一次尝试这些。 Subsonic 与实体框架一样易于设置。 我不确定实体框架是否可以像 SubSonic 那样与其他数据库一起使用，例如 MySql PGsql 等...？ 我读了这篇文章（http://www.timacheson.com/Blog/2009/jun/ entity_framework_vs_subsonic）足以令人信服地选择实体框架而不是 SubSonic。 但我想要第二次开放。
Anyone worked with Subsonic3 and Entity Framework here who can tell me the pros and cons?
This is my first time attempting to try these. Subsonic is easy to setup so as the Entity Framework. I am not sure if Entity Framework works with other databases as SubSonic does like MySql PGsql etc...?
I read this post (http://www.timacheson.com/Blog/2009/jun/entity_framework_vs_subsonic) which is convincing enough to chose Entity Framework over SubSonic. But I wanted a second opening.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果这有帮助，在我的基准测试中我使用了 Subsonic 2.1（如上所述），并在中等负载场景（如上所述的方法）中比较了数据访问层。 我提供了代码，因此我的测试可以轻松复制。
如果您对系统施加负载，在使用时重现 Web 应用程序中的条件，事实证明 EF 可以提供更好的性能。 整个 Web 应用程序的负载测试证实了这一点。 在更复杂的测试中，EF 的优化功能（例如延迟加载）可以提供比 Subsonic 更大的性能优势。
如果您比较各个数据访问操作，例如在简单的单元测试中，Subsonic 似乎更快。 特别是，Subsonic 的初始化速度更快。
如果性能是关键考虑因素，我会推荐 Fluent NHibernate 或实体框架。
In case this helps, in my benchmarks I used Subsonic 2.1 (as stated) and compared data access layers in a moderate load scenario (methodology as stated). I provided code, so my test can easily be replicated.
If you subject the system to load, reproducing the conditions in a web application while in use, EF proves to offer much better performance. Load tests of the complete web application confirm this. In more complex tests, the optimisation capabilities of EF such as lazy-loading can offer yet greater performance advantages over Subsonic.
If you compare individual data access operations, e.g. in a simple unit test, Subsonic appears to be faster. In particular, Subsonic initialised more quickly.
I would recommend Fluent NHibernate or Entity Framework if performance is a key consideration.
嗯，这两个是完全不同的野兽！
Subsonic 3 是一个很棒的工具，可以简单轻松地将数据库结构以几乎 1:1 的方式映射到对象类，其中每个类都是底层数据库中表的精确表示（就像 Linq-to-SQL 的情况一样）出色地）。
另一方面，实体框架针对更复杂的场景，其中您的域或对象模型（您的类）不一定会 1:1 映射到数据库表。 这就是 EF 具有 XML 文件三部曲的原因 - 一个描述概念级别（域对象），一个描述存储级别（数据库布局），以及这两者之间的映射。
恕我直言，Subsonic 3 和 Linq-to-SQL 非常适合快速、中小型项目，在这些项目中，您的数据库足够灵活，可以根据需要进行更改，并且可以非常简单地将对象映射到表。 EF 在大型企业应用程序中确实大放异彩，在这些应用程序中，您的数据库级别可能是一成不变的，您无法更改它 - 或者即使底层数据库发生变化，您的应用程序也需要“生存”。
在我看来，完全不同的野兽 - 完全不同的观众。
Marc
PS：我想知道 Tim 在这次比较中是否真的使用了 Subsonic 3，以及他到底在做什么。 我的直觉是 EF 的开销会“更大”，因此性能可能会稍差一些（但更灵活，在企业场景中，即使为此牺牲一些性能，它也是物有所值的）
Well, these two are quite different beasts!
Subsonic 3 is a great tool for simply and easily mapping a database structure pretty much 1:1 to object classes, where each class will be an exact representation of the table in the underlying database (as is the case with Linq-to-SQL as well).
Entity Framework on the other hand targets much more complex scenarios, where your domain or object model (your classes) will not necessarily map 1:1 to database tables. That's why the EF has a trilogy of XML files - one describing the conceptual level (your domain objects), one the storage level (the database layout), and the mapping in between those two.
IMHO, Subsonic 3 and Linq-to-SQL are perfect for quick, small to medium size projects, where your database is flexible enough to change if need be, and where you have a pretty straightforward mapping of your objects to tables. EF really shines in large-scale enterprise apps, where your database level might be set in stone, and you can't change it - or your app needs to "survive" even if the underyling database changes.
Totally different beasts - totally different audiences, in my opinion.
Marc
PS: I wonder if Tim was really using Subsonic 3 in this comparison, and what exactly he was doing. My gut feeling would have been that EF would be the "bigger" overhead and thus might be a bit less performant (but more flexible, and in Enterprise scenarios, that's worth its weight in gold, even when sacrificing some performance for it)