问题 正确的文件夹结构

米切尔恩11

活跃成员
已加入
2020年4月10日
留言内容
39
编程经验
Beginner
这可能是一个话题,但使用.NET Core MVC时应该如何设置文件结构。

创建新项目时,将获得以下信息:
C#:
>>Dependencies
>>Properties
>>wwwroot
>>Areas
>>Controllers
>>Data
>>Models
>>Services
>>Views
>>appsettings.json
>>Program.cs
>>Startup.cs

现在,我创建了一些项目,并开始工作,只有我觉得专业人员会看我的文件夹结构,然后感到恶心。
我从整个MVC设置中得到的是:
模型:建立记录和字段的地方,可能意味着数据库
控制器:所有工作都在哪里进行
视图:用户实际看到的应用程序的前端。

在项目中,我只是将方法放在相关的控制器中
IE:
>>Controllers
>>>EmployeeController
>>>>根据小时率计算工时的方法

当然可以,但是这只是初学者编程吗? (我是哪个)
就是它"根据小时率计算工时的方法"应该在自己的方法文件夹中?
我见过人们为不同的方法创建自己的库。这是否意味着整个MVC设置不遵循干净的体系结构?这就是为什么较新的.NET Core Web应用程序不再附带控制器,模型或视图(现为页面)的原因吗?
如果存在不特定于单个模型的方法怎么办?

我对构建Web应用程序感到迷茫。

是否有人拥有用于架构或文件结构的良好资源?

只是作为一个好奇的初学者来问问题。
一切都会有帮助的。谢谢。
 

金西尼

C#论坛主持人
工作人员
已加入
2011年4月23日
留言内容
3,563
地点
悉尼,澳大利亚
编程经验
10+
从广义上讲,模型是数据,视图是UI,而控制器是逻辑。从更具体的意义上讲,Controller应该是PRESENTATION逻辑,而Model应该是专门用于View的数据。您还应该具有单独的业务逻辑(通常称为服务层),以及单独的数据持久层,该层负责在应用程序和数据库之间双向移动数据。数据在数据库和视图之间可能会多次改变形状。您可能在不同层中具有用于相同数据的实体类,DTO和视图模型。服务层和数据层可以只是Web应用程序项目中专用文件夹中的类,但最好将它们放在专用项目中,因为这将在专业级项目中完成,尤其是在团队合作中。这是我参与项目已有一段时间的项目的解决方案资源管理器

1593145662976.png


这些项目如下:

Dto:包含数据的轻量级类,用于在服务层和Web应用程序之间移动数据
全局:在多个其他项目中使用的类型
映射:使用AutoMapper在EF实体和DTO之间自动映射
模型:实体框架上下文
服务:包含业务逻辑的具体类型
Service.Interface:用于单元测试业务逻辑的接口
Service.Ioc:IoC(控制反转)容器,用于将服务接口映射到具体类型
Service.Test:服务层单元测试
Web:MVC应用程序项目
Web测试:应用程序层单元测试
 

米切尔恩11

活跃成员
已加入
2020年4月10日
留言内容
39
编程经验
Beginner
从广义上讲,模型是数据,视图是UI,而控制器是逻辑。从更具体的意义上讲,Controller应该是PRESENTATION逻辑,而Model应该是专门用于View的数据。您还应该具有单独的业务逻辑(通常称为服务层),以及单独的数据持久层,该层负责在应用程序和数据库之间双向移动数据。数据在数据库和视图之间可能会多次改变形状。您可能在不同层中具有用于相同数据的实体类,DTO和视图模型。服务层和数据层可以只是Web应用程序项目中专用文件夹中的类,但最好将它们放在专用项目中,因为这将在专业级项目中完成,尤其是在团队合作中。这是我参与项目已有一段时间的项目的解决方案资源管理器

查看附件994

这些项目如下:

Dto:包含数据的轻量级类,用于在服务层和Web应用程序之间移动数据
全局:在多个其他项目中使用的类型
映射:使用AutoMapper在EF实体和DTO之间自动映射
模型:实体框架上下文
服务:包含业务逻辑的具体类型
Service.Interface:用于单元测试业务逻辑的接口
Service.Ioc:IoC(控制反转)容器,用于将服务接口映射到具体类型
Service.Test:服务层单元测试
Web:MVC应用程序项目
Web测试:应用程序层单元测试


这非常有帮助,谢谢。
设置方式是否有名称?我遇到过六角建筑,洋葱建筑和尖叫建筑。

另外,这种默认的MVC文件夹结构是否过时?
default-mvc-folder-structure.PNG
 

跳伞者

工作人员
已加入
2019年4月6日
留言内容
2,604
地点
弗吉尼亚州切萨皮克
编程经验
10+
创建的默认MVC结构适合于规模相对较小的团队的快速独立项目,如今似乎受到青睐。上面包含多个项目的设置是一种较旧的N层方法,该方法曾经非常流行,尽管每个主要组件都在其自己的项目中,但是可以生成一个单独的程序集并与其他Web应用程序共享以重新使用。我认为,对单个项目的转换部分是因为意识到每个Web应用程序实际上在其内部紧密地耦合在一起,并且不同Web应用程序之间几乎没有共享。

上面的多库/ N层方法的主要优点是。它允许进行更有针对性的单元测试。如果您不想这样做,则不必运行其他人的单元测试。
 

金西尼

C#论坛主持人
工作人员
已加入
2011年4月23日
留言内容
3,563
地点
悉尼,澳大利亚
编程经验
10+
我们这样做的原因之一是它允许服务层由网站(MVC)或Web服务(Web API)引用。如果将所有内容构建到网站中,然后需要使网站与Web服务交互,则需要拉出所有服务和数据访问代码并将其移动。由于MVC和Web API如此相似,实际上并不太困难,但这仍然是浪费时间。就是说,一旦您决定选择一种方式,实际上很少需要改变。只是一次太频繁了。
 
最佳 底部