从零开始用C#做产品：私人日记（16）内容管理设计

通过前面的教程中，我们基本实现了分类管理功能。分类的目的是为了能将内容归类，接下来我们开始本项目的重点：内容管理的设计。

首先我要声明一下，我做这款私人日记的软件产品第一主要目的是为了做自媒体教学而设定的项目，并非是一个真正的产品立项，至于以后能不能成为一个真正的软件产品我现在也说不好，基本功能完成之后再看它后续的扩展吧。之所以选择这个方向，就因为它是一个比较大众化的需求，没有专业门槛，大家比较容易理解和接受。

当然我做事情从来都不会只考虑一点，这个项目也并非绝对没有它的市场。

我之所以选它的有三个主要原因：

一是安全性的考虑。我自己的一些信息，比如工作上的想法和计划、要做的项目和任务、一些常用但又很难记忆的各种代码、每个月的收支流水、各种账号密码，或者是一些仅仅写给自己看的话，我现在很多都是以文件方式保存在硬盘的。这些敏感的内容我不大放心使用第三方开发的软件，个人或不出名的小公司肯定信不过，他们想要获取你的数据太容易了；大点公司的产品如OneNote、网易云笔记等，他们的可信度还是比较高的，但他们用的都是公有云，不管他们的安全性如何高，理论上都是存在泄露的可能性的，程序员、数据库管理员想偷偷弄点数据太容易了，万一像酒店数据那样被泄露，后果不敢想象。所以仅就这一个安全性，就足以让我不大敢用这些软件，我相信很多人会有跟我一样的感受。说到这里，有人会说，那按你的逻辑，你开发的这个软件也就只有你自己敢用了，别人也同样不敢用你的软件。是的，所以，这个项目我选择了开源，源码是公开的，如果信不过，完全可以把代码复制下来自己编译。所以在单机私人日记这个软件产品上，就天生有了它的优势。

当然权限上是安全了，但硬件上却不安全了，单机软件最怕的就是哪天硬盘突然挂了。其实也有很多解决方案：

• 自动备份到其他网络存储设备；
• 自建svn服务器，安装客户端进行同步；
• 程序中提供插件，支持oss、git、云盘等接口；

二是便利性的考虑。基于第一点安全性的考虑，这里貌似就只能跟Windows资源管理器的功能相比了，其他软件功能再多我也信不过。首先Windows资源管理器完全依赖其他的应用，比如我只想写点文字和配图，但我貌似必须得额外装个软件，Word或WPS；我可能有几十个私人的文档，为了防止他人复制查阅，我每个文档都要额外加密；随着其他软件的安装，附加了很多其他的功能，比如在一个文件上鼠标右键弹出框的长度就一屏从上到下了。其他还有很多，就不一一列举了。

三是扩展性的考虑。比如我现在写教程是类似这样：

按章节建好目录，然后每个目录中再创建一个doc文档和若干gif图，再把图粘到文档中，等要发布头条了，先打开wps中复制文字，然后再一张张的粘贴图片，整个过程也挺繁琐的。如果某天我的自媒体做成了，这种工作变成了我的日常，那完全可以把这个功能做到我这个软件中，直接就在软件中创建目录，跟写书一样，写好之后有个按钮，同步到头条，甚至是其他创作平台。

总之一句话，有现实需求，且现有产品存在不足，那就自行研发，想喜欢只要用c#，还有什么是做不到的呢？

以上，就是目前阶段我对此项目的认识。另外，再看下同类软件的最大不足，结合自身产品的定位，对完善自身产品也是相对有好处的。

比如微软OneNote的在应用商店的评价，我觉得就相当具有参考意义。如下两图：

此图充分说明了OneNote的立意是网络存储，因为只有这样才符合软件开发商的利益，不用云就做不到控制用户。而我们这个项目定位就是单机软件本地存储。最多的认同人数也重复说明了有广泛的需求。

这个是说字体的，这对我们的这个项目来说是很容易解决的。这就是大公司产品的弊端，做决策不是一个人说的算的。

以上，仅仅是介绍一个方法给大家，相比你的竞争对手，你的软件产品的核心功能有哪些优势，这个你自己要非常清楚。所以，大家在做软件产品选型的时候要多动脑思考，并不是一类软件产品已经有人做了你就没机会了，只要其他产品某个方面有缺陷，而你的产品恰好可以弥补，那你的产品就会有市场。另外，很多软件市场容量太小，大公司是不愿涉足的，假设一个小众软件，市场容量一年只有100万，别说大公司，就是几个人的小公司或许都没兴趣，但对个人开发者来说，已经足够了养活一家人了。

以上都是方向性的考虑，经过上述的分析，我觉得这个项目还是能看到一点前景的，即便是没做成，至少也可以给我自己以后的工作提升效率。既然方向再次明确，就继续动手。

具体到编码，这次就不考虑演示效果了。按正常的套路来，先做Model数据抽象，如下代码：

Model.Content类

namespace Diary.Model
{
public class Content
{
public int Id { get; set; }

/// 

/// 标题
/// 
public string Title { get; set; }

/// 

/// 副标题
/// 
public string SubTitle;

/// 

/// 内容类型：不同类型可以有不同的表现形式甚至编辑器，比如代码、任务列表等
/// 
public string Type;

/// 

/// 摘要
/// 
public string Summary;

/// 

/// 内容
/// 
public string MainBody;

/// 

/// 所属分类
/// 
public int CategoryId;

/// 

/// 创建时间
/// 
public DateTime CreateTime;

/// 

/// 真实时间（指示内容对应的真实时间，比如日记内容是9.14，首次提交时间是9.15，最后修改时间是9.20）
/// 
public DateTime RealTime;

/// 

/// 最后修改时间
/// 
public DateTime ModifyTime;

/// 

/// 描述
/// 
public string Description;

/// 

/// 备注
/// 
public string Remark;

/// 

/// Tags：与Tag表多对多的关系，基于ContentTagMap表进行映射
/// 
public List Tags;
}
}

Model.Tag类

namespace Diary.Model
{
/// 

/// 内容标签类
/// 
public class Tag
{
public int Id { get; set; }

  /// 

/// 名称
/// 
public string Name { get; set; }
}
}

需要特别说明的是Model.Content类中的CategoryId和Tags：

CategoryId是文章的所属类别，从文章管理上看Content和Category是一对多的关系，每篇文章只能用一个分类，每个分类下可以有多篇文章，所以我们需要在Category类中添加一个CategoryId的变量用来定义这种关系，数据库的字段设计也跟类是相同的。

Tags是文章标签，同样的一篇文章可以展现出不同的内容属性，比如本节教程就可以有：教程、c#编程、自媒体、技术文章等等很多不同的内容属性，我们把这个称为标签。反过来，通过每个标签也可以查阅到很多相关的文章。这种不同于CategoryId，这种是多对多的关系，数据库的字段设计跟类就不大一样了。数据库需要用3个表才能准确表达出这种关系：

• Content用来存储文章内容；
• Tag用来存储Tag内容；
• ContentTagMap用来存储Content与Tag之间的关系。

以下为这3个表的数据库结构图：

Content表

Tag表

ContentTag映射表

鉴于之前的教程都有描述，操作步骤就直接跳过了：）同学们可以自行尝试，有不清楚的可以翻看之前的教程。

----------------------------------------------------

本教程尽量保证2天一更，项目源码已作为开源项目加入到Gitee，代码内容会随教程实时更新，大家有兴趣的话可以关注我，以获得最及时的更新。私信：

私人日记 可以获取Gitee的链接；

sqlitestudio 可以获取sqlitestudio的链接；

菜鸟 可以获取菜鸟教程链接；

大家阅读过程中有哪些看不懂或未尽兴的地方，可以在评论区留言，我会先记下来在后续的教程中找机会再说。

教程有帮助的话请大家帮忙关注、转发、扩散，能不能开专栏还需要你们的支持！