9

注意:这远不是关于 x 比 x 更好的帖子。很高兴不要去那里。

我是一个 .Net 人,而且一直都是,我从早期版本 2 Beta 开始使用 MVC 框架,之后的每个版本。在过去的几个月里,我一直在搞乱 Rails,我有一个关于架构的问题,这两个平台之间似乎有很大的不同。(基于社区和 SO 等网站上的问题)

在 .Net MVC 中,我们被鼓励分离关注点,创建单独的项目来处理数据访问、业务逻辑和视图,我们还被告知我们应该在数据对象到达视图之前将它们转换为 ViewModel 等

在 Rails 中,事情似乎更简单,我们有一个包含验证、数据访问(通过活动记录)和其他逻辑属性的对象,我们只需将其发送到视图并显示它。

那么为什么在一个框架中这种方法是可以接受的,而在另一个框架中它被认为是错误的,我们最终都会编写更多代码并创建更多文件。

注意:我不是 Rails 专家,我真的不想比较哪个比 x 更好,我正在研究这 2 个框架的高级架构,并找出其中一个框架可以接受的内容,而另一个框架不能接受。

4

1 回答 1

6

这取决于您正在开发什么类型的应用程序以及您期望它增长多少。

对于琐碎的应用程序,无需使用不同的视图和域模型使事情复杂化(但您可能想要使用单独的视图模型和实体:http: //blog.gauffin.org/2011/07/three-reasons-to-why -你应该使用视图模型/)。

对于 CRUD 应用程序,您不必将数据访问封装在诸如存储库模式之类的抽象中。

但是,如果您希望编写除琐碎或 CRUD 应用程序之外的任何内容,我鼓励您这样做。模式和原则会在您想要开始维护应用程序的那一天帮助您。您将获得更小更明确定义的类,并且业务逻辑在一个地方而不是整个应用程序中创建。

我写了一篇关于我为什么使用抽象的小博客文章:http: //blog.gauffin.org/2013/01/data-layer-the-right-way/

以及为什么封装很重要:http: //blog.gauffin.org/2012/06/protect-your-data/

于 2013-02-08T14:19:38.537 回答