我应该开始使用 LINQ To SQL 吗？
目前我正在使用 NetTiers 来生成我的数据访问层和服务层。 我使用 NetTiers 已有 2 年多了，发现它非常有用。 有时我需要查看 LINQ，所以我的问题是...
- 还有其他人从 NetTiers 转到 LINQ To SQL 吗？
- 这种转变是好事还是坏事？
- 有什么我应该注意的吗？
- 您会推荐这个开关吗？
基本上我欢迎任何想法 。
Currently I am using NetTiers to generate my data access layer and service layer. I have been using NetTiers for over 2 years and have found it to be very useful. At some point I need to look at LINQ so my questions are...
- Has anyone else gone from NetTiers to LINQ To SQL?
- Was this switch over a good or bad thing?
- Is there anything that I should be aware of?
- Would you recommend this switch?
Basically I would welcome any thoughts
.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我们的团队曾经使用 NetTiers 并发现它很有用。 但是......我们使用它的次数越多，我们就越发现它的头痛和痛点。 例如，每当您对数据库进行更改时，您都需要使用 CodeSmith 重新生成 DAL，其中涉及：
也许还有其他方法这样做，但这就是我们必须做的。 源代码的重新生成还可以，有点吓人，但是还可以。 真正的问题来自存储过程。 它不会清除任何未使用的存储过程，因此，如果您从架构中删除表并重新生成 DAL，则该表的存储过程不会被删除。 此外，这对于数据库更改脚本来说非常令人头痛，我们必须将旧数据库结构与新数据库结构进行比较，并创建一个更改脚本来更新客户端安装。 该脚本可能会运行数万行 sql 代码，如果执行它时出现问题（这种情况总是存在的），那么解决它会非常痛苦。
然后灯亮了，NHibernate 作为一个 ORM。 当然，它需要一个加速时间，但这是非常值得的。 它有大量的支持，因此如果您需要做某件事，那么很可能以前已经完成了。 它非常灵活，允许您控制它的各个方面。 它也变得越来越容易使用。 Fluent Nhibernate 的出现是摆脱所需 xml 映射文件的好方法，NHibernate Profiler 提供了一个出色的界面，可以查看幕后发生的情况，从而提高效率并消除冗余。
从 NetTiers 迁移到 NHibernate 很痛苦，但也是一种好的方式。 它迫使我们转向更好的架构并重新评估功能需求。 NetTiers 提供了大量的数据访问代码，通过其 id 获取该实体，通过其外键获取另一个实体，获取这个那个的 tlist 和 vlist，但其中大部分都是不必要和未使用的。 NHibernate 仅在需要时才使用通用存储库和自定义存储库，减少了大量未使用的代码，并真正提高了可读性和可靠性。
Our team used to use NetTiers and found it to be useful. BUT... the more we used it, the more we found headaches and pain points with it. For example, anytime you make a change to the database, you need to re-generate the DAL with CodeSmith which involved:
Maybe there are other ways of doing it, but this is what we had to do. The re-gen of the source code was ok, scary, but ok. The real issue came with the stored procedures. It didn't clean any unused stored procedures so if you removed a table from your schema and re-gened your DAL, the stored procedures for that table did not get removed. Also, this became quite a headache for database change scripts where we had to compare the old database structure to the new one and create a change script to update client installations. This script could run into the tens of thousands of lines of sql code and if there was an issue executing it, which there invariably was, it was quite a pain to resolve it.
Then the light came on, NHibernate as an ORM. It certainly has a ramp-up time to it but it is well worth it. There is a ton of support for it so if there's something you need done, more than likely it's been done before. It is extremely flexible and allows you to control every aspect of it and then some. It is also becoming easier and easier to use. Fluent Nhibernate is up and coming as a great way to get rid of the xml mapping files that are needed and NHibernate Profiler provides an excellent interface to see what's going on behind the scenes to increase efficiency and remove redundancy.
Moving from NetTiers to NHibernate has been painful, but in a good way. It has forced us to move into a better architecture and re-evaluate functional needs. NetTiers provided tons of data access code, get this entity by its id, get this other entity by its foreign key, get a tlist and vlist of this and that, but most of it was unnecessary and unused. NHibernate with a generic repository and custom repositories only where needed reduced tons of unused code and really increased readability and reliability.
我尝试在一个小项目中使用 Linq to SQL，认为我想要一些可以快速生成的东西。 我在设计中遇到了很多问题。 例如，每当您需要向表中添加列时，您基本上都必须在设计器中删除并重新添加表定义。 如果您在表上设置了任何属性，则必须重新设置这些属性。 对我来说，这确实减慢了开发过程。
LINQ to SQL 本身就很好。 我真的很喜欢它的可扩展性。 如果他们可以改进设计师，我可能会再尝试一次。 我认为该框架将受益于针对 Web 开发等断开连接模型的更多功能。
查看 Scott Guthrie 的LINQ to SQL 系列博客文章提供了一些有关如何使用它的精彩示例。
I tried to use Linq to SQL on a small project, thinking that I wanted something I could generate quickly. I ran into a lot of problems in the designer. For example, anytime you need to add a column to a table you basically have to remove and re-add the table definition in the designer. If you have set any properties on the table then you have to re-set those properties. For me this really slowed down the development process.
LINQ to SQL itself is nice. I really like the extensibility. If they can improve the designer I might try it again. I think that the framework would benefit from a little more functionality aimed at a disconnected model like web development.
Check out Scott Guthrie's LINQ to SQL series of blog posts for some great examples of how to use it.
NetTiers 非常适合生成重型且健壮的 DAL，我们在内部将其用于核心库和框架。
在我看来，LINQ（在它的所有版本中，但具体来说，我认为您要求的是 SQL）对于快速数据访问来说非常出色，我们通常将它用于更敏捷的情况。
如果不重新生成代码或 dbml 层，这两种技术的更改都非常不灵活。
话虽这么说，正确使用 LINQ 2 SQL 是一个相当强大的解决方案，您甚至可以开始使用它进行未来的开发，因为它易于使用，但我不会为了它而放弃您当前的 DAL - 如果它没有损坏。 ..
NetTiers is very good for generating a heavy and robust DAL, and we use it internally for core libraries and frameworks.
As I see it, LINQ (in all its incarnations, but specifically as I think you're asking to SQL) is fantastic for quick data access, and we generally use it for more agile cases.
Both technologies are quite inflexible to change without regeneration of the code or dbml layer.
That being said, used properly LINQ 2 SQL is quite a robust solution, and you might even start using it for future development due to it's ease of use, but I wouldn't throw away your current DAL for it - if it aint broke ...
我的经验告诉我，使用 linq 可以更快地完成工作，但对数据库的实际操作会更慢。
所以......如果你有一个小数据库，我会说去吧。 如果没有，我会等待一些改进再更改
My experience tells me that using by using linq you can get things done faster, however the actual actions to the database are slower.
So... if you have a small database, i'll say go for it. If not, i would wait for some improvements before changing
我现在正在相当大的项目（大约 150 个表）上使用 LINQ to SQL，它对我来说效果很好。 我使用的最后一个 ORM 是 IBatis，它运行良好，但需要大量的跑腿工作才能完成映射。 LINQ to SQL 对我来说表现得非常好，到目前为止已经证明它非常易于开箱即用。 在过渡过程中肯定有一些差异必须克服，但我建议使用它。
旁注，我从未使用过或阅读过有关 NetTiers 的内容，因此我不会低估它的有效性，但 LINQ to SQL 一般来说已被证明是一种极其可行的 ORM。
I'm using LINQ to SQL on fairly large project right now (about 150 tables) and it is working out very well for me. The last ORM I used was IBatis and it worked well but took alot of legwork to get your mappings done. LINQ to SQL performs very well for me and so far has proved to be very easy to use out of the box. There are definately some differences you have to overcome in transition, but I would recommend it's use.
Side note, I have never used or read about NetTiers so I won't discount it's effectiveness, but LINQ to SQL in general has proven to be an extremely viable ORM.
从快速浏览 .netTiers 应用程序框架来看，我想说，如果您已经对该解决方案进行了投资，那么它似乎为您提供的不仅仅是简单的数据访问层，您应该坚持使用它。
根据我的经验，LINQ to SQL 对于中小型项目来说是一个很好的解决方案。 它是一个 ORM，是提高生产力的好方法。 它还应该为您提供另一个抽象层，允许您将下面的层更改为其他内容。 Visual Studio 中的设计器（我相信 VS Express 也是如此）非常容易使用。 它为您提供了对象映射的常见拖放和基于属性的编辑。
@ Jason Jackson - 设计器确实允许您通过以下方式添加属性另一方面，您需要指定该属性的属性，但是您执行一次，可能比最初将表拖到设计器中要多花 3 分钟，但是数据库本身每次更改只需要一次。 这与其他 ORM 并没有太大不同，但是您是对的，它们可以使这变得更加容易，并且只查找那些已更改的属性，甚至可以为此类需求实现某种重构工具。
资源：
请注意并行 LINQ 正在开发中，以便在多核计算机上实现更高的性能。
From the quick look at .netTiers Application Framework, I'd say if you already have an investment with that solution it seems to give you much more than a simple Data Access Layer and you should stick with it.
From my experience LINQ to SQL is a good solution for small-medium sized projects. It is an ORM which is a great way to enhance productivity. It also should give you another layer of abstraction that will allow you to change out the layer underneath for something else. The designer in Visual Studio (and I belive VS Express also) is very easy and simple to use. It gives you the common drag-drop and property-based editing of the object mappings.
@ Jason Jackson - The Designer does let you add properties by hand, however you need to specify the attributes for that property, but you do this once, it might take 3 minutes longer than the initial dragging of the table into the designer, however it is only necessary once per change in the database itself. This is not too different from other ORMs, however you are correct that they could make this much easier, and find only those properties that have changed, or even implement some kind of refactoring tool for such needs.
Resources:
Note that Parallel LINQ is being developed to allow for much greater performance on multi-core machines.