您认为使用F＃实现业务逻辑层是一个好主意吗？我将使用Entity Framework作为“数据映射器”并使用C＃实现UI逻辑。
欢迎任何想法。我将不胜感激任何帮助！
感谢。
P.S。那个目的是什么？我是F＃的新手，想尝试那种语言（技术）。我必须实现一个相对较小的项目，获得F＃体验可能会很好。
答案 0 :(得分：5)
在F＃中实现“实际数据处理”可能是当前最常用的F＃，因此在F＃中实现业务逻辑似乎是一个不错的选择。
我认为你不能直接从F＃使用Entity Framework（很容易），因此你需要使用C＃生成数据模型并将相关数据暴露给F＃。如果你想使用LINQ to SQL，那么你可以在C＃中生成映射，并使用PowerPack在F＃中编写查询（正如Mitya建议的那样）。
也许最简单的方法就是有三个项目：
数据访问层，它只使用实体框架并公开重要数据（使用IEnumerable类型，可以很容易地从F＃中使用）。
业务层，执行“实际处理”并公开可从C＃使用的几种类型。如果你声明一个class in F#那么它将像任何普通的.NET类一样被编译，所以你可以很容易地从C＃中使用它。您只需要注意不要在公共接口中使用F＃特定功能。一些建议是使用委托（而不是函数），类类型和IEnumerable（在F＃中称为seq而不是功能列表。
用户界面层调用F＃中声明的类型。如果您遵循上述简单规则，那么C＃代码可以轻松调用F＃类型。
作为旁注 - 尽管F＃不支持设计人员，但它对于用户界面编程来说非常棒（例如参见this article或我的谈话about Silverlight in F#）。您可以做的一件事是在C＃库项目中创建用户界面，将所有内容标记为公共，然后从实际控制用户交互的F＃项目中引用它。但是，这有点先进，所以我认为从业务层开始是一个好主意。
答案 1 :(得分：4)
我只能为自己说话，但在克服了最初的F＃学习曲线后，我发现：
1）我的F＃代码比C＃或C ++更简洁。
2）F＃更易于维护。
3）我可以在F＃中看清问题的解决方案。
4）我在F＃中提出的模式更容易在新程序中重复使用。
所以我肯定会考虑将F＃用于许多未来的编码任务，包括BLL。
-Neil
答案 2 :(得分：3)
你没有理由不这样做。
我只是将UI逻辑保留在C＃中，因为VS还没有对F＃UI设计提供非常好的支持。
答案 3 :(得分：2)
这根本不是一个坏主意。如果您对实体进行Linq，则可能需要F＃PowerPack - http://fsharppowerpack.codeplex.com/