如何构建 ASP.NET MVC 应用程序？
为了遵循最佳实践，我阅读了一些有关架构和模式的内容。这就是我们拥有的架构，我想知道您对它的看法以及任何建议的更改或改进 -
- 表示层 - 包含视图也需要的所有视图、控制器和任何帮助器类包含对模型层和业务层的引用。
- 业务层 - 包含其使用的所有业务逻辑以及验证和安全帮助程序类。它包含对数据访问层和模型层的引用。
- 数据访问层 - 包含对实体类进行的实际查询 (CRUD) 操作。它包含对模型层的引用。
- 模型层 - 包含实体框架模型、DTO、枚举。实际上没有对上述任何层的引用。
您对上述架构有何看法？问题是，我在阅读诸如存储库模式、领域驱动设计和其他设计模式之类的内容时感到困惑。我们的架构虽然不是那么严格，但仍然相对不错，而且运行良好，我认为并没有真正混淆事情，但我可能错了。如果有任何帮助或建议，我将不胜感激。我真的在寻找一些我错过的真正的大问题......谢谢！
I have read little bit about architecture and also patterns in order to follow the best practices. So this is the architecture we have and I wanted to know what you think of it and any proposed changes or improvements -
- Presentation Layer - Contains all the views,controllers and any helper classes that the view requires also it containes the reference to Model Layer and Business Layer.
- Business Layer - Contains all the business logic and validation and security helper classes that are being used by it. It contains a reference to DataAccess Layer and Model Layer.
- Data Access Layer - Contains the actual queries being made on the entity classes(CRUD) operations on the entity classes. It contains reference to Model Layer.
- Model Layer - Contains the entity framework model,DTOs,Enums.Does not really have a reference to any of the above layers.
What are your thoughts on the above architecture ? The problem is that I am getting confused by reading about like say the repository pattern, domain driven design and other design patterns. The architecture we have although not that strict still is relatively alright and it works well and I think and does not really muddle things but I maybe wrong. I would appreciate any help or suggestions here. I am really looking for some real big issues that I have missed ... Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这稍微取决于您想要特定架构的根本原因，但假设标准 MVC 应用程序具有少量关注点分离以允许互操作性和可测试性，那么您概述的结构完全正确。< /strong>
如果你这样做，那么你应该毫无例外地强烈执行它。说模型层“实际上没有引用任何上述内容”有点含糊 - 它应该不引用任何更高级别。
其他方面（例如存储库模式）将作为数据层实现的方式引入 - 它并不规定层本身。
It slightly depends on the underlying reasons as to why you want a particular architecture, but assuming a standard MVC application with a small amount of separation of concerns to allow for interoperability and testability then the structure you have outlined is exactly right.
If you go for this then you should enforce it strongly with no exceptions. Saying the Model layer "Does not really have a reference to any of the above" is a bit vague - it should not reference any of the higher levels.
Other aspects such as a repository pattern would be introduced as the way in which the data layer is implemented - it does not dictate the layers themselves.