我的公司有一个应用程序,它以编程方式在web.config文件中存储一个值. web.config文件大约每五分钟更新一次.

James Curran发表在这个答案Dynamically change connectionString in web.config中以编程方式修改web.config是一个坏主意,但他没有解释为什么这是一个坏主意.

我正在寻找说服我的老板不在web.config文件中存储任何动态数据的理由.特别感谢与优秀文章的链接.

每次修改web.config时,应用程序都会重新启动.

我正在开发针对非技术用户的应用程序。我期望有大量关于丢失密码和无法登录的支持电话。

我正在使用ASP.NET成员资格提供程序，提供3个选项来存储密码 – 清除文本，散列，加密。

鉴于此应用程序的性质，将密码存储在明文中是个好主意？在明文存储密码中是否存在任何法律问题？

决不。

从来没有一个很好的理由将密码存储在数据库中。特别是不明文您应该只存储密码的哈希值。

您可以对用户做的最糟糕的事情是通过互联网以明文电子邮件广播其“恢复”密码。简单地存储不能恢复的密码的单向散列是如此容易。

对于丢失的密码，您只需重置其密码，并为他们提供登录时必须更改的临时密码。安全可靠。

人们经常为多个应用程序(特别是非技术用户)使用相同的密码。因此，您的应用程序可能包含人民银行帐户，电子邮件等的密码。

您有责任保护用户的密码，无论您的应用程序多么微不足道。

我们正在使用MVC 2 RC2开发一个相当大的应用程序,并且我们收到了一些有关使用实体框架的延迟加载方式的反馈.

我们只是在控制器中获取实体,并将它们作为模型发送到视图,这导致视图代码要求数据库获取我们正在使用的导航属性.我们已经看过这个,看起来不是一个好的设计,但是我们想知道为什么？

你能帮我们理解这个设计问题吗？

谢谢！

这里的主要问题是耦合.模型背后的想法,即“MVC”中的“M”,它没有外部依赖.它是您的应用程序的“核心”.精心设计的应用程序架构的依赖关系树应该是这样的：

                       +---------------------------------------> Views
                       |                                           |
                       |                                           |
                       |                                           v
                  Controllers ----+-> Model Transformer -----> View Model
                       |           \         |
                       |            \        |
                       v             \       v
Data Access <---- Persistence --------> Domain Model
                       |             /
                       |            /
                       v           /
                     Mapper ------+

现在我意识到说“这里是一个架构,这是你应该使用的”并不完全令人信服,所以让我来解释一下这里发生了什么：

>控制器接收请求.
>控制器调用某种持久层(即存储库).
>持久层检索数据,然后使用映射器映射到域模型.
>控制器使用变压器将域模型更改为视图模型.
>控制器选择必要的视图并应用视图模型.

那么为什么这么好？

>域模型没有依赖关系.这是一件非常好的事情,这意味着执行验证,写测试等很容易.这意味着您可以在架构中的任何地方更改任何内容,并且永远不会破坏模型.这意味着您可以跨项目重用该模型.
>持久层返回域模型的实例.这意味着它可以被建模为一个完全抽象的,与平台无关的界面.需要使用持久层(例如控制器)的组件不承担任何其他依赖关系.这是理想的持续层的依赖注入,再次是可测试性.持久性,数据访问和映射器的组合可以生成在其自己的程序集中.在较大的项目中,您甚至可以进一步解析映射器并使其在通用记录集上运行.
>控制器只有两个下游依赖关系 – 域模型和持久层.该模型很少会改变,就像您的业务模式一样,由于持久化层是抽象的,所以几乎不需要更改控制器(添加新操作除外).
>视图取决于单独的UI模型.这使它们免受域模型的变化.这意味着如果您的业务逻辑更改,则不需要更改项目中的每个视图.它允许视图“看起来”应该是“愚蠢的” – 它们不仅仅是视图数据的占位符.这也意味着使用不同类型的UI(即智能客户端应用程序)重新创建视图或切换到不同的视图引擎(Spark,NHaml等)应该很简单,

现在,当使用诸如Linq的O / R映射器到sql或实体框架时,将它们生成的类视为域模型是非常诱人的.它看起来像一个域模型,但它不是.为什么？

>实体类与您的关系模型相关联,随着时间的推移,您的关系模型将与您的领域模型大相径庭;
实体类是哑的.很难支持任何复杂的验证场景或集成任何业务规则.这被称为贫血域模型.
>实体类具有隐藏的依赖关系.虽然它们似乎是普通的POCO,但它们实际上可能隐藏了对数据库的引用(即延迟关联的加载).这可能会导致数据库相关的问题引起视图逻辑,您最不能正确地分析发生了什么并进行调试.
>但最重要的是,“领域模式”不再是独立的.它不能生活在任何程序集的数据访问逻辑之外.那么可以这样做,如果你真的在工作,有办法去做,但这不是大多数人这样做的方式,即使你这样做,你会发现域的实际设计模型被限制到您的关系模型,特别是EF的行为.最重要的是,如果您决定更改持久性模型,则会破坏域模型,而您的域模型是应用程序中其他所有内容的基础.

实体框架类不是域模型.它们是数据关系模型的一部分,并且具有与域模型中的类相同或相似的名称.但依赖管理方面却是世界分明的.使用从ORM工具生成的类作为域模型只能导致非常脆弱的架构/设计;您对应用程序的几乎任何部分所做的每个更改都将具有一系列可预测和不可预测的级联效应.

有很多人似乎认为你不需要一个凝聚力,独立的领域模型.通常的借口是(a)它是一个小项目,和/或(b)他们的领域模型真的没有任何行为.但小项目变大,业务规则变得越来越复杂,一个贫穷或不存在的域名模型不是简单的重构.

这实际上是实体模型设计中最阴险的特征;似乎工作正常,一段时间.当你淹没在缺陷报告和变更请求中时,你不会发现这是一个错误,直到一年或两年,而拼命地将真正的领域模型拼凑在一起.

我试图建立一些启发式来帮助我决定使用适当的std ::线程类.

据我所知,从最高级别(最简单易用,但最不灵活)到最低级别,我们有：

> std :: async with / std :: future(std :: shared_future)(当你想在一次性抛出的生产者线程异步时执行)
> std :: packed_task(当你想要分配一个生产者,但是延迟对线程的调用)
> std :: promise(???)

我认为我有一个正确的把握,什么时候使用前两个,但我仍然不清楚std :: promise.

std :: future与std :: async调用相结合,有效地将生成的回调/函子/ lambda转换为异步调用(根据定义立即返回).一个单一的消费者可以调用std :: future :: get()来阻止调用,以获得结果.

std :: shared_future只是一个允许多个消费者的版本.

如果要将std :: future值与生产者回调绑定,但是希望将实际调用延迟到稍后的时间(将任务与生成线程相关联),则std :: packaging_task是正确的选择.但是现在,由于std :: package_task的相应std ::未来可能会在一般情况下被多线程访问,所以我们可能需要注意使用std :: mutex.请注意,使用std :: async,在第一种情况下,我们不必担心锁定.

读了some interesting links on promise后,我觉得我理解了它的机制和如何设置它,但是我的问题是,你什么时候可以选择使用其他三个承诺？

我正在寻找更多的应用程序级答案,如经验法则(填写上面的3.),而不是链接中的答案(例如使用std :: promise来实现一些库机制),所以我可以更容易地解释如何选择适当的类到std :: thread的开始用户.

换句话说,有一个很有用的例子,我可以用一个std :: promise做的,不能用其他机制做的.

回答

一个std ::未来是一个奇怪的野兽：一般来说,你不能直接修改它的值.

可以修改其价值的三个生产者有：

> std :: async通过异步回调,这将返回一个std :: future实例.
> std :: packed_task,当传递给线程时,它将调用其回调,从而更新与该std :: packaging_task关联的std :: future实例.这种机制允许生产者的早期绑定,但是稍后的调用.
> std :: promise,它允许通过其set_value()调用修改其关联的std :: future.通过直接控制std :: future的突变,我们必须确保设计是线程安全的,如果有多个生产者(使用std :: mutex是必需的).

我想SethCarnegie’s answer：

An easy way to think of it is that you can either set a future by
returning a value or by using a promise. future has no set method;
that functionality is provided by promise.

有助于澄清什么时候使用承诺.但是,我们必须记住,std :: mutex可能是必要的,因为承诺可能会根据用途从不同的线程访问.

另外David’s Rodriguez’s answer也很出色：

The consumer end of the communication channel would use a std::future
to consume the datum from the shared state,while the producer thread
would use a std::promise to write to the shared state.

但是作为一种替代方案,为什么不只是简单地在结果的stl容器上使用std :: mutex,并且生成器的一个线程或线程池对容器执行操作？使用std :: promise,而不是买我,除了一些额外的可读性vs一个stl容器的结果？

在std :: promise版本中,控件似乎更好：

> wait()将在给定的未来阻塞,直到产生结果
>如果只有一个生产者线程,则不需要互斥体

以下google-test通过helgrind和drd,确认使用单个生产者,并使用wait(),不需要互斥体.

测试

static unsigned MapFunc( std::string const& str ) 
{ 
    if ( str=="one" ) return 1u; 
    if ( str=="two" ) return 2u; 
    return 0u;
}

TEST( Test_future,Try_promise )
{
    typedef std::map<std::string,std::promise<unsigned>>  MAP; 
    MAP          my_map;

    std::future<unsigned> f1 = my_map["one"].get_future();
    std::future<unsigned> f2 = my_map["two"].get_future();

    std::thread{ 
        [ ]( MAP& m )
        { 
            m["one"].set_value( MapFunc( "one" ));
            m["two"].set_value( MapFunc( "two" ));
        },std::ref( my_map ) 
    }.detach();

    f1.wait();
    f2.wait();

    EXPECT_EQ( 1u,f1.get() );
    EXPECT_EQ( 2u,f2.get() );
}

你不要选择使用承诺,而不是使用承诺,而是使用承诺来与其他人一起实现未来. cppreference.com的代码示例给出了使用所有四个代码示例：

#include <iostream>
#include <future>
#include <thread>

int main()
{
    // future from a packaged_task
    std::packaged_task<int()> task([](){ return 7; }); // wrap the function
    std::future<int> f1 = task.get_future();  // get a future
    std::thread(std::move(task)).detach(); // launch on a thread

    // future from an async()
    std::future<int> f2 = std::async(std::launch::async,[](){ return 8; });

    // future from a promise
    std::promise<int> p;
    std::future<int> f3 = p.get_future();
    std::thread( [](std::promise<int>& p){ p.set_value(9); },std::ref(p) ).detach();

    std::cout << "Waiting...";
    f1.wait();
    f2.wait();
    f3.wait();
    std::cout << "Done!\nResults are: "
              << f1.get() << ' ' << f2.get() << ' ' << f3.get() << '\n';
}

版画

Waiting…Done!

Results are: 7 8 9

期货与所有三个线程一起使用以获得其结果,并且第三个线程使用承诺,以通过除返回值之外的方式来实现未来.此外,单线程可以通过承诺实现具有不同价值的多个期货,否则它将无法实现.

想到这一点的简单方法是,您可以通过返回值或使用承诺来设置未来.未来没有设定方法;该功能由承诺提供.您可以根据情况允许,选择您需要的.