人们使用什么工具来查询他们的读取数据库和填充 DTO?
我们目前在 Sql2008 数据库中拥有我们的读取模型,并通过 WCF 服务执行所有查询,我们正在使用 Fluent NHibernate 使用自动映射填充数据协定,但也许这只是矫枉过正?
我们的要求真的是这样...
- Webservice中没有Sql代码
- Web 服务中没有映射代码,理想情况下我们希望按照约定进行映射,读取数据库字段与我们的数据协定属性具有相同的名称。我们不想手动编写和维护映射代码。
- 网络服务器上的资源使用最少。
恕我直言,矫枉过正。
我只使用带有 JSON/ProtoBuf 序列化的平面文件系统。Web 服务非常简单,模式可以是任何东西。堆栈可轻松移动到云(使用 Azure 存储 Blob),以根据需要实现几乎无限的可扩展性。
详情:http ://abdullin.com/journal/2011/1/19/scalable-and-simple-cqrs-views-in-the-cloud.html
我使用 WCF 数据服务在读取方面取得了很大的成功。我写了一篇关于它的博客文章。查看http://blog.fossmo.net/post/WCF-Data-Services-A-perfect-fit-for-our-CQRS-implementation.aspx
我在数据库中使用了带有存储过程的 ADO.NET 核心。然后使用我写的一个工具,所有的数据访问代码都是使用每个存储过程的结果作为Dtos的结构生成的。
带有源代码的工具可在我的博客 Data Access Layer CodeGen上找到
现在,由于您只是通过 WCF 服务返回数据,因此无需从 DataReader 转到 Dto,然后对 DTO 进行序列化。换句话说,您在发送数据的过程中对结果集进行了 3 次迭代。因此,如果您想减少服务器上的资源利用率并获得更好的性能,那么您可以使用该工具生成的“DataReader-Wrapper”类(以及数据访问代码)。
DataReader 包装类类似于强类型 DataReader。我有另一篇文章讨论这些及其好处 DataReader Wrappers - TypeSafe
当然,您可以修改该工具(因为您也有源代码)以生成所有代码,包括 WCF 服务。所以你真正需要做的就是编写一个存储过程,你就完成了。如果您明白我的意思,所有的 DataAccess 代码(使用 ADO.NET Core - 所以它是轻量级和超快的)、业务层代码和 WCF 代码实际上只是“忙于工作”。
编辑 使用存储过程的原因