重新启动正常的线程(Restarting normal Threads)

 什么是可以接受的是非常主观的，但如果你想做适当的数据访问，我建议你不要使用存储库模式，因为随着你的应用程序变得越来越复杂，它就会崩溃。 
 
 最大的原因是最小化数据库访问。 因此，例如查看您的存储库并注意GetUser()方法。 现在退出代码并考虑应用程序将如何使用。 现在考虑一下您多长时间无需额外的数据就可以从用户表中请求数据。 除非您正在创建基本的数据录入应用程序，否则答案几乎总是“很少”。 
 
 你说你的应用程序会显示很多网格。 该网格中的数据是什么？ 我假设（不知道您的应用程序域）网格将用户数据与其他与该用户相关的信息组合在一起。 如果是这样的话，你如何使用你的仓库？ 
 
 一种方法是单独调用每个存储库的方法，如下所示： 
 
var user = userRepository.GetUser("KallDrexx");
var companies = companyRepository.GetCompaniesForUser(user.Id);
 
 现在这意味着你有2个数据库调用，真正应该只有一个。 随着屏幕变得越来越复杂，这会导致数据库点击次数增加和增加，并且如果您的应用程序获得大量流量，则会导致性能问题。 在存储库模式中执行此操作的唯一方法是将特殊方法添加到存储库以执行特定查询，如： 
 
public class UserRepository
{
    public User GetUser(string userName)
    {
        // GetUser code          
    }

    public User GetUserWithCompanies(string userName)
    {
        // query code here
    }
}
 
 那么现在如果您需要用户并在一个查询中说出他们的联系人数据会发生什么。 现在，您必须将另一种方法添加到您的用户存储库。 现在说你需要做另一个查询，它也返回每个公司的客户数量，所以你需要添加另一个方法（或者添加一个可选参数）。 现在说你想添加一个查询，返回所有公司以及他们包含的用户。 现在你需要一个新的查询方法，但是你会把它放在User存储库或Company存储库中吗？ 你如何跟踪它所处的位置，并在GetUserWithCompany需要时在GetUserWithCompany和GetCompanyWithUsers之间进行选择？ 
 
 从那时起，所有东西都变得非常复杂，这就是让我放弃存储库模式的情况。 我现在所做的数据访问是创建单独的查询和命令类，每个类代表1（且只有1个）查询或数据更新命令到数据库。 每个查询类都会返回一个视图模型，该视图模型仅包含我需要的特定用户使用场景的数据。 还有其他的数据访问模式也可以工作（规范模式，一些好的开发人员甚至说你应该在控制器中进行数据访问，因为EF 是你的数据访问层）。 
 
 成功完成数据访问的关键是做好规划。 你知道你的屏幕会是什么样子吗？ 你知道用户如何使用你的系统吗？ 你知道所有的数据实际上将在每个屏幕上？ 如果其中任何一个的答案都是否定的，那么您需要退后一步并忘记数据层，因为数据层是（或者应该是一个好的应用程序），这取决于应用程序实际上将如何使用时，UI和屏幕不应该依赖于数据层的设计方式。 如果您在开发数据访问时不考虑您的用户界面需求和用户使用场景，那么您的应用程序将无法很好地扩展并且性能不佳。 有时候，如果你的网站规划不是很大，那么这不是问题，但是记住这些事情永远不会让人感到伤心。 

What's acceptable is pretty subjective, but if you want to do proper data access I suggest you do NOT use the repository pattern, as it breaks down as your application gets more complex.
 
The biggest reason is minimizing database access. So for example look at your repository and notice the GetUser() method. Now take a step back from the code and think about how your application is going to be used. Now think about how often you are going to request data from the user table without any additional data. The answer is almost always going to be "rarely" unless you are creating a basic data entry application.
 
You say it your application will show a lot of grids. What data is in that Grid? I'm assuming (without knowing your application domain) that the grids will combine user data with other information that's relevant for that user. If that's the case, how do you do it with your repositories?
 
One way is to call on each repository's method individually, like so:
 
var user = userRepository.GetUser("KallDrexx");
var companies = companyRepository.GetCompaniesForUser(user.Id);
 
This now means you have 2 database calls for what really should be just one. As your screens get more and more complex, this will cause the number of database hits to increase and increase, and if your application gets significant traffic this will cause performance issues. The only real way to do this in the repository pattern is to add special methods to your repositories to do that specific query, like:
 
public class UserRepository
{
    public User GetUser(string userName)
    {
        // GetUser code          
    }

    public User GetUserWithCompanies(string userName)
    {
        // query code here
    }
}
 
So now what happens if you need users and say their contact data in one query. Now you have to add another method to your user repository. Now say you need to do another query that also returns the number of clients each company has, so you need to add yet another method (or add an optional parameter). Now say you want to add a query that returns all companies and what users they contain. Now you need a new query method but then comes the question of do you put that in the User repository or the Company repository? How do you keep track of which one it's in and make it simple to choose between GetUserWithCompany and GetCompanyWithUsers when you need it later?
 
Everything gets very complex from that point on, and it's those situations that have made me drop the repository pattern. What I do now for data access is I create individual query and command classes, each class represents 1 (and only 1) query or data update command to the database. Each query class returns a view model that only contains the data I need for one specific user usage scenario. There are other data access patterns that will work too (specification pattern, some good devs even say you should just do your data access in your controllers since EF is your data access layer).
 
The key to doing data access successfully is good planning. Do you know what your screens are going to look like? Do you know how users are going to use your system? Do you know all the data that is actually going to be on each screen? If the answer to any of these is no, then you need to take a step back and forget about the data layer, because the data layer is (or should be for a good application) determined based on how the application is actually going to be used, the UI and the screens should not be dependent on how the data layer was designed. If you don't take your UI needs and user usage scenarios into account when developing the data access, your application will not scale well and will not be performant. Sometimes that's not an issue if you don't plan on your site being big, but it never hurts to keep those things in mind.