https://hub.docker.com/r/microsoft/dotnet/

https://www.codeproject.com/Articles/1109475/Modular-Web-Application-with-ASP-NET-Core

http://qun.qq.com/guide.html

针对某些参数不能写在项目中的问题, 可以开启一个新的项DotNetLive.ApplicationConfigurationManager的项目，专门做配置项管理.

程序启动的时候从这个项目获取启动相关配置.

与现有的Json文件的配置一样，增加一个AddRemoteConfiguration的配置, 从远程服务器获取配置信息.

这样可以彻底解决某些关键信息在代码中的问题.

#项目召集各位能人义士(留言请注明相关经验年限, 以及行为偏好, XX取向可以自由说明)

• 架构师(.Net Core)
• .NET Core开发(高级/中级/初级)
• 前端开发(Angular2/VueJS/React/BootStrap)
• 项目Leader

参与之后你将学习.NET Core, 前端技术, 文档编写, 系统架构设计, 项目管理

在问问题之前请先移步DNL Docs(http://docs.dotnet.live)了解项目概要,

其次是什么人可以报名: 如果你对上面的技术感兴趣，如果还认为这个项目能让你学习到更多的知识，接触到更多的业内人士，那你就是这个项目需要的人.

如还有问题请再下面留言或者开新的Issue.

报名或者有想法的同学可以先了解一下GIT库里面的代码或者能在GITHUB里面找到的文档, 相信你会发现不少好东西, 因为项目所需要的东西我们只有一个地方存放，那就是GITHUB, 所以这也要求你必须熟悉GITHUB的用法, 这个熟悉不仅仅是GIT的使用，还有Issues, Wiki, 以及DotNetLive Docs, 这个站点也在GITHUB里面.

我们遵守的规则:
Rule #1: 逐步放弃QQ等及时聊天工具，学会用Github Issue与Wiki沟通.

祝你有一个好的开始.

很多场景我们都需要进行图片，文档的存储，列举几个具体的场景:

1. 发布博客内容图片
2. 用户的头像
3. 各个子系统上传的用户附件

传统方案:
规划一个大的磁盘，按照不同的应用规划子目录，这样得方案在文件服务器迁移的时候有大量文档资料需要处理，效率非常低下，并且不能保证不丢失.

新的方案:
正在评估用Mongodb来集中存储，并且可以做到横向扩容

有能力的同学可以来领这个任务, 有相关经历的人欢迎主动申请.

通过ElasticSearch提供DNL系统内各子系统(产生内容的子系统)的搜索工作, 目前有博客系统，论坛系统.
希望有Elk这方面经验的人提供设计方案与参与实现.

1. 命名
2. 注释

项目原型是除的文档以外的最有指导性意义的东西，目前正在安排开发中:

• 纯前端原型
• MVC Web端原型
• WebApi端原型

1. 前后彻底分离，把API放在一台机器。其他的前端项目放在其它服务器。这样访问速度快

2. 可以大家先集中起来做一个产品出来，这样的好处就是项目的基本架构出来了。大家也有成就感。其他产品可以基于这个产品做。扩展性要高，代码规范也出来了。不然重构次数容易多。如果同时进行几个项目，代码规范很难控制。

3. 尽快确定底层所需要采用的技术，比如访问数据库是只支持dapper还是同时支持ef(ef复杂场景下还不稳定)

最终DotNetLive.Framework各个项目的nuget更新有几点要注意

1. 必须是自动打包发布, 所以肯定要放到Jenkins上去做编译发布, 不会是人手工打包发布,.
2. 既然我们的核心是Cross Platform, 所以整个过程必须是在Linux(特指非Windows平台)上完成

大家Controller下面的Action方法都加上注释声明
/// 注释 切勿使用【//】
vs会根据/// 注释生成一份XML文档
我会提取xml的内容进行自动化文档生成

在常规的系统当中，日志分散在各处，非常不便于集中查看分析处理，在排查问题的过程中往往需要花很多的时间在各种日志之间来回分析, 特别是在子系统数量上升之后，各系统间的交互日志, 跨系统问题排查效率会再次降低.

日志可视化:
这个方案要从三个点着手处理,

1. 日志收集
2. 日志分析再处理
3. 日志查询展示

希望有日志处理经验的同学来接手这个任务.

转自: #2
每个接口的输入输出参数都采用独立Model序列化和反序列化，便于维护
@pinzi

两点建议

1. 采用前后端分离+webapi的方式进行开发，
2. 每个接口的输入输出参数都采用独立Model序列化和反序列化，便于维护。(Move to #4 )