Azure Function项目结构(C#与CSX)和最佳实践 [英] Azure Function Project Structure (C# vs CSX) and Best Practices

问题描述

最近我得到了其他用C#脚本(.csx)编写的开发人员Azure函数代码，我以前是使用Visual Studio编写Azure函数的.

Recently I got other developer Azure function code written in C# Script (.csx), I used to write Azure function using visual studio.

我喜欢C#脚本命令式绑定，它使代码更容易(无需管理连接)

I love C# Script imperative binding, it make code more easy (no need to manage connections)

我看到了C#脚本的一些问题

I saw some problem with C# Script

1. 代码质量工具不起作用(StyleCop/Sonar)
2. 无法针对.csx文件编写单元测试

如果您有其他意见，请分享.

If you have a different opinion, Please share.

所以我决定将所有功能(10)转换为具有声纳集成和UnitTest的.net项目.

So I decided that I will convert all functions(10) into .net project with sonar integration and UnitTest.

问题 我的大多数功能都没有任何业务逻辑，它们从EventHub获取触发器并将数据转储到cosmos DB中，但是我无法决定在单个解决方案下应该创建10个项目还是1个项目?

Question My most of functions not having any business logic they are getting triggers from EventHub and dumping data into cosmos DB, I'm not able to decide should I create 10 projects or 1 project under single solution?

我相信具有多个功能的单个项目具有单个

I believe single project with multiple function having single host.json file, If I will change host.json value for scaling particular function, it will impact other function as well. Am'I right?

功能数量=项目数量是正确的解决方案吗?

Number of function = number of project is a correct solution?

它将如何影响成本?

推荐答案

个人认为CSX文件适合用于实验或快速而又肮脏的东西，但对于生产而言，应使用编译的c#.

Personal opinion is the CSX files are fine for experimenting or something quick and dirty but for production you should be using compiled c#.

调整host.json文件中的任何设置都会影响该功能应用程序中的所有功能.关于何时将您的功能分解为单独的应用程序，没有一个普遍正确的答案，但是您可以问几个问题，以帮助您针对自己的情况进行回答:

Adjusting any setting in the host.json file will impact all functions within that function app. There is no universally correct answer on when to break out your function into separate apps but there are a few questions you can ask to help answer it for your scenario:

1. 特定功能的缩放特性是否与其他功能大不相同. (例如，您的某个消息触发器是否与其他消息触发器获得了截然不同的消息量或处理逻辑-您是否需要更改host.json)
2. 您的功能是在执行单独的业务流程，然后是其他功能(例如，一个正在接收设备遥测消息，而另一个正在处理审计遥测)
3. 做#1和#2证明创建一个单独的功能应用程序的管理和开发开销是合理的(很多功能应用程序，尤其是像架构这样的微服务，在管理上可能是一个挑战)

在您的情况下，您对函数应用程序具有一定的灵活性，因为它们只是消息侦听器，如果您以后想将函数分解为单独的应用程序(例如，http端点)，它们不会像http触发器那样受到太大的影响.更改).

In your case you have some flexibility with your function apps because they are just message listeners they aren't impacted as much as say http triggers if you find you want to break out the function into a separate app later (e.g. http endpoints changing).

这篇关于Azure Function项目结构(C#与CSX)和最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！