每个表一个存储库或每个功能部分一个？

Question

我正在使用ASP.NET MVC 2和C#与Entity Framework 4.0来对规范化的SQL Server数据库进行编码.我的数据库结构的一部分包含一个条目表,其中包含与包含驱动程序,汽车,引擎,机箱等的子表相关的外键.

我正在遵循Nerd Dinner教程,该教程为晚餐设置了一个公平的存储库.我会为司机做一个,为引擎做一个,为汽车做一个等等,还是做一个大的参赛作品？

这类工作的最佳做​​法是什么？我对这种编码方法还很陌生.

Answer 1

我猜这里没有单一的"最佳实践" - 这取决于您的编码风格和应用程序的要求.您肯定可以为系统中的每个实体类型创建一个存储库 - 这样就可以了.

在你的情况在这里,我可能会至少考虑为驱动程序库,可能第二个用于汽车,发动机,底盘(因为这些是有点在同一专业领域 - 他们是相互关联的,他们"属于"在一起).

但是:当然,如果汽车,引擎和机箱的单一存储库过于膨胀,您可以考虑将其分解为三个单独的存储库.

我会去找库的数量之间的平衡 - 尝试组一起什么逻辑上属于一起 - 而在这些资料库的方法数.五,十个方法是好的 - 如果你说20,30或50的方法,你的资料库可能只是过大而笨重.

这绝对是一个建筑决策,因此,它们并不是真正指导你的很多事实 - 它更像是一种"直觉"和经验之类的东西.如果你还没有那种必要的经验 - 采用一种方法,使用它,当你完成后 - 再次以批判的眼光看待它并看看:它有什么用呢？怎么样没用呢？然后在你的下一个项目中,尝试一些其他方法,并在项目结束时质疑其有效性.活到老,学到老!

Answer 2

就个人而言,我发现最好为每个表创建一个单独的存储库.

然后我services layer在一个类中创建一个where我将运行特定操作的所有命令(例如,将已经存在的驱动程序的汽车更改为新添加的汽车).如果我需要完成的操作包含多个相互关联的对象,那么服务层就是我将调用多个存储库的地方.

我尽力保持我的存储库尽可能"愚蠢",并将所有"智能"的东西放在服务层.额外的services图层也可以帮助我避免控制器膨胀.

Answer 3

我正在为每个实体使用通用(参数化)存储库.该存储库包含基本的CRUD功能.在此之上,我为每项功能提供服务.每个服务都实例化所需的存储库.ObjectContext对所有这些都是通用的,每个请求都有一个.这是我的存储库界面:

public interface IRepository<T>
{
    //Retrieves list of items in table
    IQueryable<T> List();
    IQueryable<T> List(params string[] includes);

    //Creates from detached item
    void Create(T item);
    void Delete(int id);
    T Get(int id);
    T Get(int id, params string[] includes);
    void SaveChanges();
}

我也有通用的实现,这很长,但很容易实现.您不必为每种类型创建存储库类,只需实例化即可Repository<Type>.

Answer 4

我通常采用数据库的图表并在我认为是更大的单元或系统的周围画圈。

这让我在商店中得到类似 "ProductSystem" 、 "OrderSystem" 、 "UserSystem"、"PaymentSystem" 的东西。

如果系统变得太大，我会将它们分开。

如果系统太少，我不在乎：无论如何，一切都会增长。

如果某物以某种方式属于 2 个系统，我会选择 1 并且不再更改它，即使第二天决策错误：我知道我想再次将其更改回来的那一天。