我们正在为预先存在的MongoDB数据库构建ASP.NET前端。在这种情况下，我们为ASP开发人员提供强类型体验有哪些选择？以下是我能想到的一些选择：
第一个选项并不是很好，因为微软世界的开发人员习惯了更自动的东西。
第二个选项更有趣，尽管MongoDB的本质可能会让社区难以创建这样的工具。 （即，＆＃34;架构＆＃34;可能因同一集合中的文档而异。）
最后一个选项让我很担心，因为它似乎意味着放弃了最简单的.Net API体验（MongoDB.Driver提供的体验，我理解它是MongoDB.Driver.Core之上的一个外观）。
建议？
谢谢， 乙
答案 0 :(得分：0)
选择选项1。
理解，实施和制作数据模型（或域模型，或DAL模型，或您选择的任何架构）非常重要，并且，就像地图不是领土一样，< strong>数据库方案不是模型（并且无法从模式中推断出）[假设 是一个一致的结构，从中可以推断出架构开始与]
第二种选择更有趣，尽管[...]＆＃34;架构＆＃34;可以在同一集合中的文档之间变化
这就是为什么这可能不是一个好方法的一个论点。另一个问题是，从MongoDB数据类型到.NET没有1：1的映射。例如，默认情况下，decimal存储为字符串（以防止规范化等），但它也可以存储为双精度，例如 - 具有执行范围查询的能力在数据库中，但没有小数精度。字典可以存储为列表列表，对象列表等等......同样，ObjectId可以在.NET中表示为ObjectId（强类型，但引入了对MongoDB的依赖性）司机），或作为一个字符串......
平底船。即，坚持使用.Net的一个或多个可用MongoDB客户端公开的Document和Field类型，并将其称为一天。
.NET开发人员习惯于在严格打字的环境中工作，并且它使每个操作都非常麻烦......将0.2添加到字符串中？哦等等，我可以使用Double.Parse！哦等等，我经常这样做，让我们写一个类...更糟糕的是嵌套文档，容器等等。
第一个选项并不是很好，因为微软世界的开发人员习惯了更自动的东西。
我避开创建代码的工具：如果你想到面向对象的开发，你为什么要离开创建最重要的类那些带状态，到工具的那些？