ASP.NET数据访问层的设计决策

我有一套静态数据库访问层类，可以对车辆，经销商和大量跟踪记录进行CRUD操作。这些对象在内存消耗方面可以相当大，因为记录的音符等等。我们称这组类为“A”。ASP.NET数据访问层的设计决策

另外，我还有另一个名为Lookups的静态类，它为了填充DropDownLists而执行只读操作。返回非常非常精细的对象（只是一个ID和一个文本字段） - 我们称之为“B”类

类“B”中的方法从与集合“A”中的方法相同的表中读取。

B中的部分代码看起来与“A”中的代码相似，只是返回的是较小的对象。

我违反了B中的DRY原则，但仅仅是因为我不想为了填充下拉列表而返回大对象。我希望这个系统具有可扩展性，以便在RAM上轻松使用。但我不禁想到可能有更好的方法，设计明智。

你会推荐什么？

对于下一个项目，我将使用实体框架，但这是老派的ADO.NET手动编写的SqlConnection和SqlCommand对象。

来源

2013-05-30 user1154016

我想你应该为你的业务逻辑的每个实体都有一个存储库。就像这样：

// dealing only with Vehicle operations 
public interface IVehicleReposity { 
    // Operations.. 
} 

public class VehicleReposity: IVehicleReposity { 
    // Impementiong operations and 
    // calling your static methods 
}

这将允许您随时更改您的业务逻辑。正如你将能够称之为静态方法，实体框架或Nhibernate，如果你想要有一天..

在这种情况下，你不会重复自己，你将能够在依赖注入easlly 。

来源

2013-05-30 10:52:49 Mata

嗨马塔，我目前有VehicleDA，DealerDA和HireDA类，其中每个处理各自实体的CRUD操作。 – user1154016

我打算加上DA = Data Access。另外，我还有一个LookupDA，可以从与这些对象相同的数据库表中读取数据。因为LookupDA从相同的表中读取，这意味着有一些重复的代码。这是DRY违规，但我认为这是最有效的内存。然而，我正在与自己对抗，认为某处有气味 – user1154016

ASP.NET数据访问层的设计决策

回答

相关问题