1

我终于决定跳上 MVC 2 的火车。现在我最近做了很多阅读，下面是我认为对于大多数业务 Web 应用程序来说足够好的架构。

分层架构：-
模型（与数据库通信的层）。EF4
存储库（与模型通信并包括所有查询的层）
业务层（验证、帮助函数、对存储库的调用）
控制器（控制应用程序的流程并负责从业务层向视图提供数据。）
视图（用户界面）

现在我决定为每一层创建一个单独的项目（只是为了尊重关注点分离的困境。虽然我知道这没有必要但我认为它使项目看起来更专业:-)

我正在使用AutoMetaData t4 模板进行验证。我也遇到了FluentValidation但找不到太多关于它的信息。我应该和哪一个一起去？

选择哪个视图引擎？
Razor View Engine一见钟情。但它仍处于测试阶段，我认为要找到它的例子并不容易。我对吗？
Spark ..我也找不到太多关于它的信息，也不想在没有人听的时候被困在中间的某个地方寻求帮助......:-(

T4 模板自动生成视图，我可以自定义它们以按照我想要的方式生成视图？剃须刀和火花可以做到这一点，还是我必须手动创建它们？

有没有办法自动生成存储库？

如果我能看到基于上述架构的项目，我将不胜感激。

请让我知道这是否是一个很好的架构。
我对业务层有些困惑，比如真的有必要吗？

4

4 回答 4

0

有时从代码中学习模式更容易：Sharp Architecture 是 MVC 中良好实践的具体实现，使用 DDD。

于 2010-11-08T19:07:56.243 回答
0

这是一个非常广泛的问题。我决定将 Fluent NHibernate 的自动配置功能用于一个新的应用程序，并且给我留下了深刻的印象。我的很多同事都使用 CakePHP，它只需要很少的配置就可以生成与 cake 使用的默认约定兼容的数据库模式，这对我们来说非常棒。

于 2010-10-31T18:21:56.453 回答
0

我强烈推荐这本书 ASP.NET MVC2 in Action。本书很好地涵盖了用于制作可维护的 ASP.NET MVC 应用程序的库生态系统。

至于视图引擎的选择，这可能取决于您的背景。我个人更喜欢我的视图看起来尽可能像 HTML，所以我会选择 Spark。另一方面，如果您习惯使用 ASP.NET 经典版，WebForms 视图引擎可能会让您以最快的速度启动和运行。

于 2010-10-31T18:23:29.417 回答
0

请让我知道它是否是一个好的架构？

这是一个好的开始——我建议您添加的唯一内容是业务逻辑和数据访问之间的抽象层（即：依赖倒置/注入）——请参阅：依赖倒置简介。

我知道这没有必要，但我认为它使项目看起来更专业:-)

哈！通常你会发现很多“东西”是不必要的——直到需要的那一刻，此时通常为时已晚。

重新查看引擎：我自己还是 ASP.NET MVC 的新手，因此不熟悉您所说的视图引擎；如果我是你，我会想出一些测试场景，然后尝试用每种产品处理它们，这样你就可以直接比较它们。通常，您需要采取一些措施让试驾更加舒适——尽管这可能需要时间，但通常是值得的。

编辑：

如果我向我的 PM 建议这一层并给他上述两个理由，那么我认为他不会接受

首先，PM不是技术主管（通常）；您负责解决方案的设计 - 而不是 PM。这并不少见，根据我的经验，在大多数情况下，总理甚至都不知道他们正在侵占您不存在的地盘。这并不是说我是一个“政治土地掠夺者”，而是我只是倾向于考虑“关注点分离”，嗯，我相信你明白。

作为设计师/架构师，由您来解释需求并（考虑业务优先级）提出提供最佳“平台”的解决方案。

（关于 DI）我的问题是，这真的值得吗？

如果你拿枪指着我的头，我会说是的，但是现实世界要复杂一些。

如果您对任何这些问题的回答是肯定的，那么使用 DI 更有可能是一个好主意：

  • 该系统不平凡
  • 该系统的预期寿命超过（不确定这里的正确数字，可能没有，所以我将在地面上投入股份）2 年。
  • 系统和/或其要求是流动的。
  • 将工作（BL / DAL）分成不同的团队将对项目有利（也许您是分布式团队的一部分）。
  • 该系统适用于具有多样化技术环境的市场（例如：不是每个人都想使用 MS SQL）。
  • 您想要执行质量测试（这会更容易）。
  • 该系统很大/很复杂，因此可以拆分功能并将其放入其他系统中。
  • 您希望提供不止一种数据存储方式（例如免费的基于文件的存储库，以及收费的数据库驱动存储库）。
  • 业务驱动程序/环境是不稳定的——如果他们来找你说“这很好，但现在我们想提供一个基于云的版本，你能把它放在 Azure 上吗？”

我还想指出，虽然肯定有一个学习曲线，但它并没有那么大，一旦你跟上进度，你至少仍然会和现在一样快；或者在最坏的情况下，您将花费更长的时间，但您将提供更多的价值（相对较少的努力）。

至于付出多少努力...

一次性任务（除了让团队加快速度之外）：

  • 编写 Provider Loader 或选择 DI 框架。完成此操作后，它将可以在您的所有项目中重复使用。

“新”常见任务（假设您遵循文章中采用的方法）：

  • 定义接口（在纸上）——无论如何，这都是你现在要做的事情，只是你可能没有意识到。基本上它是 OO 设计，但由于它将成为两个或多个包之间的正式接口，您需要考虑一下（是的，您仍然可以重构它 - 但理想情况下，接口应该是“稳定的”并且不会发生太大变化；如果它确实发生了变化，最好“添加”而不是“删除或更改”现有成员）。
  • 编写接口代码。这非常快（几分钟而不是几小时），因为您没有编写任何实现；当你去实现时，你可以使用你的 IDE 提供的工具来生成基于接口的代码存根。

你现在做的事情，你会做不同的事情：

  • 实例化一个变量（在您的 BL 类中）以保存提供者，可能通过工厂。编写这个不应该花费很长时间（同样，几分钟而不是几小时），并且它是相当简单的代码，可以在需要的地方复制、粘贴和重构。
  • 编写 DAL 代码：应该和以前一样。
于 2010-10-31T22:35:40.723 回答