Closed. This question is
opinion-based。它当前不接受答案。
想改善这个问题吗？更新问题，以便
editing this post用事实和引用来回答。
去年关闭。
Improve this question
背景故事：大家好，我只是花了很多时间阅读这里和其他站点上的许多LINQ vs Nhibernate线程。我在一个由4人组成的小型开发团队中工作，我们甚至没有真正经验丰富的开发人员。我们为一家小型公司工作，该公司具有大量技术需求，但没有足够的开发人员来实现这些需求（现在不再有可能雇用更多员工）。
通常，我们的项目（分别很小）分别进行了编码，无论如何都没有真正分层，没有重复使用代码，没有类库，我们只是将LINQtoSQL .dbml文件用作项目，所以甚至不使用对象，而是传递值和内容，我们唯一使用对象的时间是在插入数据库时（甚至不需要查询，因为您无需将其分配给类型并且可以绑定到gridview）。尽管我说过所有这些，但是我们公司有很多技术需求，但是一年没有人来找我们，我们将进行大量工作来实现所需的功能。
好吧，我决定首先通过创建类库并实际在我们的应用程序中添加层来稍作更改。制作具有总体功能的优秀应用程序的机会很大。我试图通过仍然使用LINQtoSQL作为ORM并仍然使用VB作为语言来与这些家伙碰面。但是，我发现在LINQtoSQL中处理很多事情的时间到了，我在Nhibernate中发现很容易（会话的自动处理，准则创建比表达式树更容易，泛型的动态查询更容易等）。 ..
问题：如何使我的主要开发人员和其他高级程序员相信切换到Nhibernate是件好事？控制我们的领域对象是一件好事吗？能够实现接口是一件好事吗？我之前曾尝试说明这种方法的优点，但是它们并没有被他们理解，因为它们从未以真正的面向对象和分层的方式进行编程。
我可以看到的与此相反的参数之一是sqlMetal自动生成这些类，因此节省了大量时间。除了说花更多的时间在基础架构上以使其具有更高的可扩展性和灵活性之外，我无法反驳这一点，但是他们看不出怎么做。
同样，我知道它们的特性和优点（我相信的足够多），但是我需要适用于我的上下文的论据，因此为什么要提供背景故事。我猜我不是一个很好的辩手。
（注意：对于所有LINQtoSQL爱好者，我可能不像LINQ那样精通，但是我发现非常麻烦，您需要下载一些额外的库用于动态查询，这些查询默认情况下不支持guid比较，而且我也从数据上下文管理的角度来看，发现更新实体的方法也很麻烦，所以可能只是我很烂。）