EF 和存储库模式

发布于 2024-10-13 08:31:06 字数 479 浏览 3 评论 0原文

我正在用 MVC 编写一个项目并使用 EF 4.0。我正在使用存储库模式，但不确定在哪里放置一些属性。

public interface IUserRepository<User> 
{
    User GetUserById(int userId);
    void UpdateUser(User user);
    void AddUser(User user);
    List<User> GetUsersByName(string userName);             
    void Create(User user);      
    int NumberOfFollowers { get; set; }     
}

我的两个问题是1）。属性 NumberOfFollowers 应该是属性还是方法？和2）。应该放在User实体类中而不是接口中吗？

干杯。

原文

I am writing a project in MVC and am using EF 4.0. I am using the repository pattern but am unsure about where to place some properties.

public interface IUserRepository<User> 
{
    User GetUserById(int userId);
    void UpdateUser(User user);
    void AddUser(User user);
    List<User> GetUsersByName(string userName);             
    void Create(User user);      
    int NumberOfFollowers { get; set; }     
}

My two problems are 1). should the property NumberOfFollowers be a property or a method?
and 2). should it be placed inside the User entity class instead of the interface?

cheers.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

假装爱人 2024-10-20 08:31:07

NumberOfFollowers 将是用户本身的属性，而不是在存储库界面中。

回复收藏 0 原文

初雪 2024-10-20 08:31:07

我同意丹尼尔的回答 - 拥有一个名为 NumberOfFollowers 的属性是最合乎逻辑的。作为指导，如果您可以通过 User 对象本身访问数据，则直接在 User 类上创建属性\方法。通常，如果您有其他表的外键，则可以通过 User 类访问这些数据项，并且应该封装在属性\方法内。

另一方面，如果您想要查找与User 相关的信息，但需要另一个对象的帮助，则创建一个UserService 类。保持存储库简单 - 仅具有数据检索\操作方法，并在单独的服务类中创建更多涉及/业务逻辑的方法，例如

public class UserService {
    private DbContext Context {get; set;}

    public IList<Document> GetUserDocument(User user)
    {
        // Assuming User table does not have a Document ID as a foregin key..
        // Do whatever you need to do to get document.
    } }

上面是粗略的指南，绝不是事实上的标准，但它对我来说效果很好。

I will agree wilth Daniel's answer - having a property named NumberOfFollowers would be most logical. As a guide, if there is data you can access via the User object itself, then have properties\methods created directly on the User class. Oftern if you have foregin keys to other tables, then accessing those data items can be done via the User class and should be encapsulated inside properties\methods.

On the other hand, if you wanted to find information relating to a User, but would require another object's help, then create a UserService class. Keep the repository simple - have data retrieval\manipulation methods only, and created more involved/business logic hungry methods in a seperate service class e.g.

public class UserService {
    private DbContext Context {get; set;}

    public IList<Document> GetUserDocument(User user)
    {
        // Assuming User table does not have a Document ID as a foregin key..
        // Do whatever you need to do to get document.
    } }

The above is rough guide and by no means the defacto standard, but it works well for me.

回复收藏 0 原文