Wpf 这种架构策略是否适用于用F#编写的业务应用程序？

我一直在考虑如何只使用F#和WPF编写业务应用程序。以下是我对如何实施的总体思路，但我正在寻找它是否有效：

从ADO.NET实体开始，自动生成数据访问层

由于F#不支持分部类，因此使用F#扩展方法创建一个BLL，该BLL使用额外的成员扩展实体对象（这些将必须改变实体）

与其编写显式的ViewModels，不如编写F#函数，使用对象表达式动态构建ViewModel对象

在给定ViewModel对象作为输入的情况下，编写一个F#函数，该函数使用活动模式和决策树动态构建WPF视图。它还负责在视图和ViewModel对象之间设置绑定

因此，打开表单或页面需要执行一个函数来生成ViewModel对象实例，然后将其传递给从ViewModel构建视图的函数，然后将其设置为窗口的内容。从那时起，它以正常的“可变”MVVM方式执行

我对F#的了解仍然有限，所以我可能走错了方向

问题:

• 这（一般）行得通吗
• 你知道有更好的方法吗

这应该行得通（虽然我不确定可变实体，因为我不是F#专家）

---

但我关心的是性能：F#使用了大量递归，特别是在决策树的情况下，这在运行时需要做大量工作。我会考虑预先生成一切或缓存系统。使用元编程在运行时生成是可以的，但为什么每次都要这样做，而您只能这样做一次呢？

我对ADO.NET实体、MVVM或WPF了解不多，所以我个人无法对这些技术思想提出太多批评。听起来你对所有这些技术都有经验，并且知道那里发生了什么。所以我唯一的评论是，听起来有太多的新事物需要一次尝试。为了降低风险并增加成功的机会，我将在几个项目中进行此阶段。例如，可以从使用现有工具的传统数据层开始，尝试一下您对F#View&ViewModel的想法。一旦你解决了问题，对F#感到更舒服，然后试着处理数据层

也要注意

其中包括例如F#的MVVM入门模板，以防它们提供任何想法/价值（我不清楚您的战略与传统有多大的不同，以了解这是否有帮助）

下面是另一个可能有价值也可能没有价值的随机链接：

---

我建议跳过ADO.NET实体，只定义不可变的记录。你能在第二段展开吗？我已经读了好几遍了，我不知道你的技术观点是什么。我只是从F#开始，但我会给出以下两条评论：1。F#确实使用了大量递归，但只要使用tail recursion（）进行递归调用，就不会出现性能/内存问题（F#编译器比C#更优化这些问题）。2.默认情况下，F#中的实体是不可变的-它们可以显式地变为可变的-但是如果您经常这样做，那么很可能您没有以“F#方式”进行操作。在（4）中，您正在动态构建XAML视图。您可以做的是创建一个缓存系统或预先生成XAML。预生成意味着生成XAML，并像其他任何应用程序一样在WPF应用程序中编译它。另一方面，缓存系统类似于动态调用（每次调用时，您首先查看是否已生成此类视图，如果已生成，则获取视图，否则生成视图）。尾部递归就像循环一样，但并不总是能够将函数调用转换为尾部递归，它将取决于实际的函数调用。尾部递归和递归不是一回事^^^@Kel:True。我认为这种功能性方法的强大之处在于我可以编写它，然后如果需要提高性能，我可以在以后添加缓存，而无需太多麻烦。我同意该视图大部分是静态的，但主要因用户而异（由于安全权限），这是（3）中函数的输入。您当然可以缓存给定用户会话的（3）和（4）输出。您的最终链接正是我所想的。将可变内容隐藏在计算表达式中，并返回漂亮的不可变记录。不需要ADO.NET实体的膨胀。我试图绕过的是手动创建视图模型和视图。我在C#中确实有很多这样做的经验，你很快就会意识到“样板”并不能很好地做到这一点。尤其是在ViewModels中，您花费了大量时间编写重复的粘合逻辑，这简直是胡说八道。我的想法是F#可以动态生成这些，因为它是如此重复。@ChaosPandion:我不可能这样写：行。[“FirstName”]；因为当你的模式改变时，你就有大麻烦了。另外，重点是对实体进行变异，然后调用Save（毕竟大多数业务屏幕都是编辑屏幕）。说“只需编写不可变的包装器”很好，但a）它可以自动化吗，b）当用户单击“保存”时，如何跟踪更改并更新数据库？@Scott。。。这不是我的专长，但与其拥有知道如何保存自己的可变数据类型，不如拥有不可变的数据类型和知道如何保存它们的不同类型？您的编辑屏幕将从原始数据对象开始，并通过将其替换为修改后的副本来进行更改。类似于.Net字符串“突变”。编辑完成后，它会保存最后一个对象。@Scott-如果你真的想最大限度地利用F#，你不应该强迫地思考。把它想象成一个系列