实体框架 - C#或VB.Net

Question

我的公司正在考虑在.NET 4发布时使用Entity Framework。我们目前是VB.NET的开发环境，但有一些兴趣转换到C#。

这样做有什么主要的赞成或反对的观点吗？
相比VB.NET，EF与C＃是否在性能、编码易用性等方面具有优势？

感谢您的想法/意见！

- Airn5475

---

跟上市场术语，现在不是 .0 了，只是 4 ;) - Nate

非常抱歉对此疏忽表示歉意！;D - Airn5475

你可能想要接受一个你感到满意的答案。这有助于让人们意识到你的问题已经解决了。 - JonH

Answer 1

如果说实话，我其实对vb.net有一种不合理的厌恶，我更喜欢c#的语法，但是没有什么强制性的理由让我去切换。它们都编译成IL，只有微小的差异，并且同样具备能力。

我想最有说服力的原因可能是，招募高质量的c#开发人员比vb更容易。

- Paul Creasey

Answer 2

我总是说要坚持自己擅长的事情。如果从vb.net到C#有很大的学习曲线，那可能会有风险。我曾经是一名vb.net程序员，但后来转向了C#，我并没有觉得很困难。但如果你正在开发一些需要每日更改/修复的强大软件，你可能希望坚持自己擅长的领域（在这种情况下是VB.net）。 这里有一个关于两种语言的不错比较。 当你比较两种语言的实体框架时，你不会发现太大的区别。如果你喜欢使用公共子函数和匹配的结束子函数（更冗长），那么就使用vb.net。如果你喜欢{ }和更少的冗长，那么就选择C#。

我不想告诉人们不要学习C#，因为说实话，我希望很早之前就从VB.net转到C#。我喜欢这种加密的语法，因为我有C/C++背景。由于一些内部应用程序，我不得不处理VB.net一段时间。所以这是个人偏好，你可能会更快地在VB.net中实现所有的东西。但如果你的公司愿意让你们学习一门新语言并投资于你们的知识，那我建议全力支持C#。

- JonH

---

C# 绝对是一个不错的投资！谢谢你的想法！ - Airn5475

Answer 3

我认为你最大的问题不在于性能或能力上的差异，而是文档。MSDN可能会提供两种语言的功能，但大部分博客文章等都是用c#编写的。这些文章可能提供实际开发中的最佳实践、技巧和其他信息，这些内容将在你的开发实践中起到重要作用，而大多数内容都是用c#编写的。

- Chris Conway

---

我完全同意你的看法，Chris。我经常跑去Google/Bing查阅语法或如何进行某些操作。我本质上是个C#专家，但这份工作要求我使用VB.NET。除了外部文档和资源，我无缘无故地想回到C#。 - Airn5475

Answer 4

在.NET 4.0中，VB.NET和C#具有完全相同的功能。唯一的区别就是语法。在4.0之前，情况并非如此，因为存在一些细微的差异。然而，微软已经努力使这两种语言变得相同。这将随着4.0版本的发布而实现。

- Ben Hoffman

---

跟上市场术语，不再是.0，现在是4 ;) - Nate

与其纠结于微软的术语，不如让他们做出更好的产品。如果他们是一家聪明的公司，就应该减少术语，提高产品质量。我喜欢微软，但他们仍需改进。 - Ben Hoffman

Answer 5

对我来说，最有吸引力的区别之一是C#通常具有更简洁的语法。这在lambda表达式中尤为明显。虽然VB.Net现在也具有相同的功能，但我发现VB.Net语法过于冗长。

例如，如果您使用LINQ的“Fluent API”语法：

C#

var addresses = _users
   .Where(u => u.Name == "scott")
   .Select(u => u.Address)

不可否认，刚开始时语法可能有点奇怪，但一旦你习惯了，实际上这将变得非常易读。与VB.Net相比：

Dim addresses = _users _
     .Where(Function(u) As Boolean
                return u.Name = "scott"
            End Function) _
     .Select(Function(u) as Address
                Return u.Address
             End Function)

编辑： 显然我得到了错误的信息...

上述代码仅在VB10中有效（其中添加了多行Lambda语句），但可以更简洁地编写如下：

        Dim addresses = users _
          .Where(Function(u) u.Name = "scott") _
          .Select(Function(u) u.Address)

除了难看的下划线和使用 "Function" 关键字而非 "=>"，这基本上是相同的。尽管如此，我仍然更喜欢 C# 语法;-)

- jeroenh

---

这是否是有效的VB代码呢？通常，你应该保留"As Boolean"和"End Function"之类的东西。对于一行代码，VB.NET的语法几乎不比C＃更差。 - Eamon Nerbonne

@Eamon。像Eamon所说的那样，有效的VB并不比C#差太多。“Dim addresses = _users.Where(Function(w) w.Name = "scott").Select(Function(z) z.Address)”但对我来说，很难在VB上进行改进，“Dim addresses = From u In _users Where u.Name = "scott" Select u.Address”。 - MarkJ

我意识到我的第二个例子不是“流畅”的（按照书本的标准），但在我看来，它是可读的、极为简洁的，并且允许链接，这些是“流畅”最关键的优点。 - MarkJ

@Eamon Nerbonne，@MarkJ 我写的代码是有效的VB，但只在VB10中有效。然而，我忽略了更简洁的一行语法；我已经更新了我的答案。 - jeroenh

整个“Function(w)”是我讨厌VB.NET LINQ与C# LINQ之间的一件事情。另一件事是用于LINQ语句的行继续字符。感谢多行提示。我期待着它！ - Airn5475

关于行连续下划线 - VB团队已经在VB10的某些部分中删除了下划线的需求。我不知道他们是否在LINQ中删除了它们。让我们希望即使他们还没有完成，它也在他们的清单上。 - MarkJ

Answer 6

如果你主要是VB程序员，C#可能会让你感到困惑；所有那些晦涩的大括号，而不是一个好记的"End Sub"！

在大多数情况下，这两种语言是等效的；它们都编译成基本相同的IL（尽管有时会有差异），因此在性能上也是相同的（大多数情况下）。

底线：这是个人偏好。我更喜欢C#。你可能不喜欢。

- Randolpho

---

我个人更喜欢VB6。不，不，不！C# :) +1 因为你说得太对了，它只是输出相同的不同方言。 - Filip Ekberg

一个漂亮的冗长的“End Sub”*吐口水* ;) - johnc

Answer 7

没有实质性的区别，现在VB.NET和C#更加保持同步，最终选择取决于你（或你的公司）的个人偏好。

- Otávio Décio

Answer 8

这取决于你所在的团队和技能基础。

- Aim Kai

Answer 9

在我看来，C#是最好的选择。虽然我可以编写两种语言的代码，但我更喜欢C#。.Net世界似乎围绕着C#转。我认为你们公司会发现有更多熟练的C#程序员，而不是VB.net程序员。

- Eric

---

我喜欢你使用“revolve”的措辞。我同意。 - Airn5475

Answer 10

我认为两种语言都可以。我更喜欢C#，因为有更多的C#文档。

- PitneFor