在 MVC 中记录事件 - 哪种方法最适合？
我有一个 MVC2 Web 应用程序，需要记录用户的唯一登录次数。用户每次登录时，都需要将一条记录保存到数据库中。只是时间、日期等基本信息。
鉴于业务需求是仅在一个特定的 ActionResult 中记录案例（即用户登录），我是否应该简单地编写一些自定义代码来将记录发送到数据库？
或者，鉴于该公司确实有后来改变主意的记录（这在客户中并不常见），我是否可以更好地创建一些更强大的东西并使用它？
最后，使用 Log4Net 怎么样？鉴于最初的需求仅关注一个应用程序的一小部分，即使以后可能会更具可扩展性，这是否有点过分了？
感谢建议和热烈的辩论。
I have an MVC2 web application that needs to record the number of unique logins by users. Each time a user logs in, there needs to be a record saved to a database. Just the basics like time, date and the like.
Given that the business requirements are to log only cases in one specific ActionResult (i.e. user logon), should I simply write some custom code to fire a record through to the database?
Alternatively, given the company does have a track record of later on changing their mind (uncommon as that is with clients), might I be better to create something a little more robust and use that?
Finally, what about using Log4Net instead? Given that the initial requirements only focus on one small part of one application, is that overkill even though it might be more extensible later?
Advice and lively debate appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于您使用的是
SqlMembershipProvider，最简单的做法可能是向aspnet_Membership表添加一个更新触发器。当LastLoginDate更新时，触发器可以填充单独的跟踪表。如果您想使用FailedPasswordAttemptCount列跟踪失败的登录尝试，您也可以执行相同的操作。有关用户登录时如何更新这些字段的更多详细信息，请参阅 SqlMembershipProvider.ValidateUser 方法：
对于一般的日志记录，无论如何，您可能都想使用日志框架，我建议使用 NLog。
Since you are using the
SqlMembershipProvider, the simplest thing to do might be to add anupdate triggerto theaspnet_Membershiptable. WhenLastLoginDateis updated, the trigger can populate a separate tracking table. You can do the same if you want to track failed login attempts using theFailedPasswordAttemptCountcolumn.For more detail on how these fields are updated when the user logs in, see the documentation for the SqlMembershipProvider.ValidateUser method:
With respect to logging in general, you may want to use a logging framework regardless, and I would suggest NLog.
您描述的需求似乎非常适合应用程序/领域事件。
当用户登录时，应引发应用程序范围的事件以表明该事件（用户登录）已发生。 “事件”是一条消息，我总是将它们写成没有任何行为的数据包（除了完全公共的属性之外什么都没有），并且我通常使它们包含处理程序所需的所有上下文（数据）（通常只是一个记录ID）。
另外，为事件编写一个处理程序，在数据库中记录相关信息。处理程序应该是一个具有单一职责的类。如果需要执行更多操作来响应事件，请将它们实现为单独的处理程序。
然后，在应用程序启动的某个位置，必须连接处理程序以侦听应用程序/域事件。
因此，需要一些基础设施代码来支持这种模式，但它应该是简单且简短的代码，这通常可以得到 DI/IoC 容器的极大帮助。如果您用谷歌搜索域事件，还有许多可用的实现示例。
我发现这种应用程序/域事件模式异常非常强大。采用这种模式极大地改进了我的代码。我发现在不修改任何现有代码的情况下扩展系统的行为要容易得多，并且通过在您的示例中为用户登录的代码和记录有关应用程序登录统计信息的代码。
最后，我不会为此使用 Log4Net。如果您实现该事件，则处理程序应该非常简单明了，但如果您尝试硬塞 Log4Net 来执行持久性，那么......看来您最终将与您的工具（Log4Net）进行斗争，至少在某些方面度 - 只要不使用它就可以完全避免这种情况。
The need you describe appears to be a great fit for an application/domain event.
When a user logs in, an application wide event should be raised to signal that the event (a user logging in) has occurred. The "event" is a message, I always write these as bags of data with no behavior (nothing but fully public properties), and I usually make them contain all the context (data) necessary for the handlers (which often is simply a single record ID).
Separately, write a handler for the event that records the pertinent information in your database. The handler should be a class that has a single responsibility. If more actions need to happen in response to an event, implement them as individual handlers.
Then, somewhere in the application start-up, handlers must be wired to listen to the application/domain events.
So there will be a bit of infrastructure code required to support this pattern, but it should be simple and short code, which can often be greatly assisted by DI/IoC containers. There is also many examples of implementations available if you google domain events.
This pattern of application/domain events is one I've found to be exceptionally powerful. Employing this pattern has drastically improved my code. I find it much easier to extend the behavior of systems without modifying any of the existing code and that behavior is encapsulated by having a clear spot for, in your example, the code that logs a user in and the code that records statistics about application logins.
Lastly, I would not use Log4Net for this. If you implement the event, the handler should be extremely simple and straightforward, but if you attempt to shoe-horn Log4Net in to perform the persistence, well ... it seems you will end up fighting your tool (Log4Net) to at least some degree - and that can be avoided entirely by just not using it.