架构决策：ASP.NET MVC＆amp;实体框架

Question

我有一个架构决策问题： 我们即将构建一个新的应用程序，我们已经决定使用 ASP.NET MVC 和实体框架（数据库首先可能） ）。在第一个案例中，我们只会为常规浏览器构建Web应用程序，但将来我们可能会添加移动应用程序。 （SOA？）

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

这是正确的吗？

1. MvcProject
   • 型号
   • 查看
   • 控制器
2. DAL项目
   • 持有edmx和T4模板

我一直在寻找示例，模式和最佳做法，但我似乎找不到合适的东西。

谢谢！

Answer 1

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

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

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

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

Answer 2

听起来您的团队还没有足够的信息来做出决定。我知道这就是你在这里问这个问题的原因，但你不应该依赖于你得到的任何答案。 ASP.NET MVC和EF 可能 对您来说是一个很好的解决方案，但如果没有至少通过Nerd Dinner或Music Store工作，您就不应该选择它。教程。

完成此操作后，您将能够回答有关架构的问题，并可能会发现一些其他问题。

Answer 3

基本策略可能包含以下内容：

• 数据项目
  • EF模型
  • Entites / T4代
• 逻辑项目
  • 申请规则
  • 与数据呈现无关的逻辑
• 网站项目
  • 演示文稿/汇总逻辑（在控制器/视图中）
  • 浏览
  • 脚本/资产
  • 模型（仅用于控制器和视图之间的通信）
• 移动项目
  • 与网站相同但适用于移动目标

Answer 4

首先，您必须决定如何实施网站的移动版本。 基本上你有两个选择：

• 为您的移动页面创建单独的视图/控制器。这种解决方案是最昂贵的，但也是最灵活的。 （看看MVC 4中的移动支持）
• 为您的网站创建自适应布局（http://jquerymobile.com/）通常我更喜欢这个选项。

通常我正在使用3个项目

• DAL
  • 包含Edmx，T4模板
• 服务
  • 使用CRUD操作的服务类（我没有使用存储库，因为它们过度杀伤）
  • 查看模型
• 网络
  • 控制器，视图，......

Answer 5

我认为您选择了正确的应用程序架构，我们在其中一个项目中也使用了相同的应用程序架构......

MvcProject
Model
View
Controller

DAL project
Holds edmx and T4 templates

Answer 6

请记住，最佳架构与预算和时间表直接相关。

MVC的费用将超过常规的asp.net：

• MVC强制开发人员始终使用3层
• MVC开发人员更贵，更难获得

当你说DAL项目时，我认为你的意思是普通的asp.net。如果是这种情况，那么：

• ASP.NET开发比MVC
更快
• ASP.NET网站将允许您使用更复杂的第三方网格等。
• 美国广泛的人才

关于移动开发，您选择的网站并不重要。您的移动应用程序应使用设备的本机语言（IOS，Android等）进行开发。然后通过SSL和JSON与应用程序通信。