小编Pur*_*ion的帖子

看看Microsoft的Managed Extensibility Framework(MEF)和各种IoC容器(例如Unity),我没有看到何时使用一种类型的解决方案而不是另一种.更具体地说,似乎MEF处理大多数IoC类型模式,并且像Unity那样的IoC容器不是必需的.

理想情况下,我希望看到一个很好的用例,其中将使用IoC容器代替MEF或者除了MEF之外.

我目前正在努力确保我们的传统后端可以根据用户的当前时区(或更具体地说是偏移量)支持解析日期时间.我们的服务器处于东部标准时间,我们的大部分日期时间都来自那里.但是,对于位于其他时区的用户,在检索这些日期时间时需要转换到其时区(或者,在这种情况下为偏移).此外,来自用户的日期时间必须在服务器上持久化之前转换为东部标准时间.鉴于我们正在开发的前端是基于Web的,我能够在几分钟内检索用户的偏移量,并将该值传递到标题内的服务层.我看了Noda Time并认为它是一个很棒的API.它确实迫使我在更精致的事情中思考时间,但我仍然不能100%确定我已正确使用它.以下是我为上述转换编写的方法.我测试了它们,它们似乎有效.鉴于上述情况,这看起来是否正确使用了库？我是否正确考虑约会时间？

public static DateTime ConvertToUtcFromEasternTimeZone(DateTime easternDateTime)
{
    NodaTime.DateTimeZone easternTimeZone = NodaTime.DateTimeZoneProviders.Tzdb.GetZoneOrNull("America/New_York");
    ZoneLocalMappingResolver customResolver = Resolvers.CreateMappingResolver(Resolvers.ReturnLater, Resolvers.ReturnStartOfIntervalAfter);
    var easternLocalDateTime = LocalDateTime.FromDateTime(easternDateTime);
    var easternZonedDateTime = easternTimeZone.ResolveLocal(easternLocalDateTime, customResolver);
    return easternZonedDateTime.ToDateTimeUtc();
}

public static DateTime ConvertToEasternTimeZoneFromUtc(DateTime utcDateTime)
{
    NodaTime.DateTimeZone easternTimeZone = NodaTime.DateTimeZoneProviders.Tzdb.GetZoneOrNull("America/New_York");
    NodaTime.DateTimeZone utcTimeZone = NodaTime.DateTimeZoneProviders.Tzdb.GetZoneOrNull("UTC");
    ZoneLocalMappingResolver customResolver = Resolvers.CreateMappingResolver(Resolvers.ReturnLater, Resolvers.ReturnStartOfIntervalAfter);
    var utcLocal = LocalDateTime.FromDateTime(utcDateTime);
    var utcZonedDateTime = utcTimeZone.ResolveLocal(utcLocal, customResolver);
    var easternZonedDateTime = utcZonedDateTime.ToInstant().InZone(easternTimeZone);
    return easternZonedDateTime.ToDateTimeUnspecified();
}

public static DateTime ConvertToUtc(DateTime dateTime, int offsetInMinutes)
{
    LocalDateTime localDateTime = LocalDateTime.FromDateTime(dateTime);
    var convertedDateTime = localDateTime.PlusMinutes(offsetInMinutes).ToDateTimeUnspecified(); …

可以在生产系统中开始使用Iron Ruby和Iron Python吗？另外,托管它们还有其他要求吗？

而且,对于奖励积分,假设F#是一种与Python相同的函数式编程语言,那么在.NET框架中使用一个优于另一个是否有任何优势？

有一段时间了,我和我的团队一直在Web服务外观(使用WCF)中包装数据访问层并从业务逻辑层调用它.同时,我们可以简单地使用存储库模式,其中业务逻辑层通过接口在本地消耗数据访问层,并且在任何时间点,我们都可以切换它以使其命中服务(如果需要).

问题是:什么时候将数据访问层包装在服务外观中,什么时候不是？现在,似乎主要优势是其他应用程序可以使用该服务,但如果它们是用.NET编写的内部应用程序,那么它们只能使用.NET程序集.将DAL包含在我不知道的服务中还有其他优点吗？