需要澄清 AutoMapper 的使用
我遇到了一些道德困境，我们是否使用自动映射器，方法是否正确以及我们的架构是否有效。我是一个相对较新的开发人员，但这对我来说感觉不对。我的同事是自动映射器的忠实粉丝（可以理解，所以它很震撼），但我的问题是我们只是为了它而使用它，并试图以一种模式进行鞋拔，只是因为“这就是它的完成方式”。基本上，我们正在为一个内部应用程序构建一个 Web 扩展，该应用程序有一个 api 和一个令人讨厌的 Sql 数据库。我们创建了许多 sql 视图来提取每个屏幕所需的数据。然后使用 linq2sql 和存储库模式调用视图，然后将数据传递到服务层，该服务层自动映射数据，就像生成要传递到视图的 Viewmodel 对象一样。我的问题是，我们真的需要 autmapper 吗？我们的数据已经处于可以查看的阶段了。另外一个论点是让我们使用视图模型元数据进行控制，但这当然可以通过 linq2sql 上的伙伴类来完成实体？
我是否遗漏了一些东西，或者这看起来是不必要的复杂？另外，我一直在寻找对网格使用 teleriks 控件，但自动映射器位于我的数据和输出之间，我不确定 hom 是否可以处理这个问题？
感谢您的任何意见；）
I'm having a bit of a moral dilemma, as to if we are using automapper if the right way and if our architecture is valid. I'm a relatively new developer but this just feels wrong to me. My colleague is a big fan of automapper (understandably so it rocks) but my issue is that we are using it just for the sake of it and trying to shoe horn in a pattern just because "That's how it's done". Basically we are building a web extension to an internal app that has a api and a nasty Sql database. We have created a number of sql views to pull the data we need for each screen. The views are then called using linq2sql and a repository pattern which then passes data to a service layer that automaps the data pretty much like for like to produce the Viewmodel objects to pass to the view. My issue is that do we really need autmapper here surely our data is already at a stage where we can view.. Also one argument for this is to give us control using view model metadata but surely this could be done with buddy classes on the linq2sql entities?
Am I missing something or does this seem unessential complex? Also I've been looking to use teleriks controls for the grid but with automapper standing in between my data and the output I'm unsure of hom to deal with this?
Thanks for any input ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我已经构建了一个中等大小的 ASP.NET MVC Web 应用程序，听起来它的架构与您所描述的非常相似。我们发现，将 LINQ to SQL 对象直接作为视图模型公开给视图会在项目中产生很多摩擦，因为我们的许多视图要么组合了多个 LINQ to SQL 对象，要么仅依赖于 LINQ to SQL 对象数据的子集。
在项目后期，我们开始使用 AutoMapper 将 LINQ 映射到 SQL 对象以查看模型（以及返回），这无疑使我们的系统更加灵活。所以我会推荐它。
I've built a moderate size ASP.NET MVC web application that sounds like its architecture was very similar to what you describe. We found that exposing our LINQ to SQL objects directly as view models to our views created a lot of friction in the project, since many of our views either composited multiple LINQ to SQL objects or relied on only a subset of a LINQ to SQL object's data.
Late in the project we started using AutoMapper to map LINQ to SQL objects to view models (and back) and it definitely allowed our system to be much more flexible. So I would recommend it.