架构决策:ASP.NET MVC和实体框架

Question

我有一个架构决策问题:我们即将构建一个新的应用程序,我们已经决定我们将使用ASP.NET MVC和Entity Framework(可能是数据库).在第一个案例中,我们只会为常规浏览器构建Web应用程序,但将来我们可能会添加移动应用程序.(SOA？)

我现在的问题是构建应用程序架构的最佳方法是什么？

这是正确的吗？

1. MvcProject
   • 模型
   • 视图
   • 调节器
2. DAL项目
   • 持有edmx和T4模板

我一直在寻找示例,模式和最佳实践,但我似乎找不到合适的东西.

谢谢!

Answer 1

我通常构建我的解决方案的方式(编辑适用于NuGet)

1. 网站(MVC)
   • 控制器
   • 查看
   • 内容(脚本,CSS,图像等)
2. 演示模型(对于简单的项目,这将嵌入网站)
   • 查看模型
   • 模型映射器
3. 商业逻辑
   • 规则
   • 本地扩展(Web和常规)
4. 数据(如果复杂,请根据上下文/ repos/models使用单独的子文件夹)
   • 库
   • 实体模型
   • 数据上下文和配置
5. Web库(可能是通过本地NuGet提供的单独解决方案)
   • 扩展(到MVC/Web类)
   • 助手类=属性
6. 通用图书馆(也许是通过本地NuGet提供的独立解决方案)
   • 扩展
   • 助手课程

依赖关系流向这个结构,即上面的内容可能引用下面的内容,但反之亦然.每个项目我也会有一个单独的测试项目.在某些情况下,我使用与NuGet打包并托管在本地存储库上的Web /通用类的外部共享库.

对于移动设备,如果你要通过网络,我会使用jQuery Mobile和移动感知视图引擎将其直接构建到WebSite中.如果您正在考虑本机,那么我将添加一个WebAPI层,该层可能会或可能不会与用于API交付的网站共享相同的视图模型,并在此结构之外针对API开发移动应用程序.API最有可能拥有自己的模型,并位于单独堆栈中的业务层之上.在我目前的项目中,我们将数据放在一个单独的解决方案中,并在单独的解决方案中开发API和网站,通过NuGet包共享模型.