DTO、结果对象等放在哪里？
我有一个相当干净的 ASP.NET MVC 项目结构。 然而，我正在努力研究如何组织大量 DTO（数据传输对象）类，例如，只是封装来自表单（视图模型）的发布数据，但不代表完整的域对象或还没有任何接近的东西； 然后是我拥有的许多“结果”对象，它们将复杂的结果信息从我的服务层传递回控制器。 你把这些东西放在哪里/如何组织它们？ 我现在有一个文件夹，里面有 60 多个类，而且越来越混乱。 感谢建议！
I have a fairly clean ASP.NET MVC project structure. However, I'm struggling on how to organize the mass of classes which are DTOs (data transfer objects), e.g. just to encapsulate post data from forms (viewmodels) but don't represent full domain objects or anything near that yet; and then the many "result" objects I have which communicate complex result information from my service layer back to the controller. Where do you stuff these/how do you organize them? I have one folder with well over 60 classes now and it's getting cluttered. Appreciate suggestions!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
域对象应该存在于单独的域模型库中。 任何以框架中立的方式支持域模型的东西（例如，不引用 ASP.NET MVC、WCF、WPF 等）都属于域模型。
在域模型和特定接口框架（在您的情况下为 ASP.NET MVC）之间执行转换的类属于该特定项目（您的 ASP.NET MVC 项目）。
您可以将映射器等放在单独的 Mappers 文件夹中，但就我个人而言，我认为沿着功能而不是基础设施构建代码更有价值。
Domain objects should live in a separate Domain Model library. Anything that supports the Domain Model in an framework-neutral way (e.g. no references to ASP.NET MVC, WCF, WPF etc.) belongs in the Domain Model.
Classes that perform translation between the Domain Model and the specific interface framework (ASP.NET MVC in your case) belongs in that particular project (your ASP.NET MVC project).
You can have your mappers etc. in a separate Mappers folder, but personally, I think it is much more valuable to structure code along features instead of infrastructure.
我使用
..Core 我还使用
. .Text I use
<CompanyName>.<ProjectName>.Coreto store all project specific classes which are not strictly pertaining to the particular project interface that I am writing. So DTOs, DAOs, other project-specific classes are all in there.I also use
<CompanyName>.<DotNetLibraryNamespace>to store general purpose classes that could be reused across projects, and are not specific to this project domain. For example, string manipulation classes could go in the<CompanyName>.Textnamespace. I always mirror the .net namespace structure names so that anyone that uses the .net class library has an easy time finding my stuff.