我在一个拥有约50多名开发人员的IT部门工作。它曾经是大约100多名开发商，但由于经济衰退而被削减。
当我们的部门规模扩大时，我们已经做出了雄心勃勃的努力来建立一个特殊的建筑群。
该小组决定做的一件事是创建我们自己的内部记录器。他们认为这是一项如此简单的任务，我们可以花费资源并自行完成。现在我们遇到了性能问题和查看生成日志的困难，一些员工对我们在这样的基础设施上花费资源而不是专注于服务我们的业务和使用已经存在的东西如log4net或Enterprise Logger感到沮丧。
您能否协助我列出您不创建自己的.net记录器的原因。
欢迎
答案 0 :(得分：16)
在我上一份工作中，几乎所有基础设施都是由我们编写的，而不是使用一些现成的产品。 （以及“所有基础设施”我的意思是所有的 - 记录，消息传递，数据库，容器等）。
它最大的缺点之一是它让我们花了大部分时间来处理与最终用户无关的事情而不是添加更多功能。
从那份工作中我学会了始终专注于你的产品要解决的问题。贵公司是否正在开发伐木机？您的记录器的质量是否会影响您的客户而不是其他功能？我不这么认为。
您的预算和人力有限 - 明智地使用它。不要重新发明轮子。如果你把注意力集中在他们需要的东西上，我相信你的公司和你的客户会受益。
在我当前的项目中，我使用NHibernate作为ORM框架，而不是在其他项目中使用的内部框架。而不是修复旧的ORM框架中的错误，我的重点是项目的主要路线图。此外，NHibernate有自己的路线图，这意味着我的公司没有太多资源就可以获得额外的功能。
答案 1 :(得分：9)
我会采取不同的方法。如何首先将公共接口引入您自己的库，例如Common Infrastructure Libraries（http://netcommon.sourceforge.net/）。然后，您可以逐步将所有项目移动到该接口，如果您自己的库不适合大型项目的工作，那么只需切换到一个开源框架（甚至是商业解决方案）。
HTH 亚历
答案 2 :(得分：2)
我使用自定义日志记录API，它使用提供者模型设计，允许插入外部日志框架。我已经为Log4Net，EntLib和System.Diagnostics.Trace记录器开发了提供程序。
这与Common Infrastructure Libraries基本相同。
这意味着内部开发没有明确依赖外部日志框架，但您仍然可以从您喜欢的日志框架的所有功能中受益。在实践中，我们通常使用Log4Net，但已经使用EntLib的客户除外。
答案 3 :(得分：2)
答案 4 :(得分：2)
我不同意那些看到人们在各地重新发明轮子的人。轮子可以是数据库服务器，操作系统或编程语言。然而，像ORM框架或这个log4net的东西在市场上没有足够的时间被认为是轮子。 其中许多产品的生命周期很短，它们被新方法所取代，只考虑你看到了多少个ORM框架，然后微软推出了LINQ。 记录不是一个可以学习的坚实的学科，它非常依赖于平台。 因此，考虑使用可能过时的日志框架（log4net vs nlog），浪费时间学习它，并不排除构建自己的日志记录的选项。 我用ORM映射完成了这个，对我来说，构建一些ORM类比学习nHybernate更好。
答案 5 :(得分：1)
我写了own one因为我认为（A）它基于TraceListener，它是一个标准的.NET类，（B）它使用起来很简单，也许是因为我想写一个
但现在我在我的新项目中使用NLog并在一些旧项目中替换它！
我错了吗？这两个对我都很好，并且使用NLog的原因是我想要一个需要几乎重写我的自定义TraceListener的功能。结果是一个1或2小时的教程，示例应用程序对我来说更便宜。这不是普遍的情况;但有助于更清晰地记录日志问题。
答案 6 :(得分：0)
如果您的日志记录解决方案有这样的特殊要求，即现成的解决方案不起作用，那么制作自定义版本可能是值得的。
如果这是争论，可以考虑下载一个开源框架并尝试自定义它。