我目前正在设计一个需要访问数据库 (SQL Server) 的应用程序 (.Net WinForms)。
使用数据源向导，Visual Studio 自动为行创建数据集、表和类：
例如，如果我有 Customers 表，向导将创建从 Global.System.Data.DataRow 继承的“CustomersRow”类，并将相应的字段作为属性。
在我的应用程序中，我需要为客户类实现其他方法和属性。
如何处理这些生成的类，通过添加方法修改它们..还是忽略它们并实现自己的业务类？
第二个问题：
如何填充我的对象（例如客户列表？）
您是否建议使用数据表/数据集及其方法或构建我自己的数据访问层并且我满足客户列表（客户）？
我在网上搜索时发现了一些模式，但并不准确。
谢谢
【问题讨论】：
标签： .net design-patterns database-design data-access-layer
我也是设计模式的新手，但我认为最好的解决方案是将业务层放在生成的类和 DAL 之上。然后在这一层中，您可以为您的类实现自定义方法和属性，也许您应该考虑为此使用 POCO 对象。
【讨论】：
当涉及到层和层时，请保持简单。一些开发人员在业务层方面变得非常学术，但他们所做的只是增加不必要的复杂性（注意architecture astronauts）。所以我的第一个建议是为您的特定应用程序保持简单和易于维护。
我们的目标是在维护复杂性和灵活性之间取得平衡。您希望您的应用能够灵活地扩展，而无需进行大量更改，但同时，您希望能够拥有一个易于理解的应用程序。
在持久性和客户端之间至少有一层是一件好事。这使您可以灵活地将域和/或服务置于客户端和数据库之间。除非您要解决特定问题，否则我不会超出此范围。
至于从你的持久化加载，你可以使用部分类来扩展生成的持久化类。这是一种在保持原始属性和方法完好无损的同时添加其他功能的简单方法。
如果您需要将持久性对象转换为应用程序使用的域对象，我建议将构造函数或静态 Create 方法放在接受持久性对象的域对象上，然后将其转换为域对象。你可以做同样的事情回到持久性。
using MyApp.Domain;
public class Customer
{
public string Name { get; set; }
public string Address { get; set; }
public int ID { get; set; }
public static MyApp.Domain.Customer Create( MyApp.Persistence.Customer pcustomer )
{
return new MyApp.Domain.Customer
{
Name = pcustomer.Name,
Address = pcustomer.Address,
ID = pcustomer.ID
}
}
public void Persist( MyApp.Persistence.Customer pcustomer )
{
pcustomer.ID = this.ID;
pcustomer.Name = this.Name;
pcustomer.Address = this.Address;
}
}
这就是分部类的样子。关键是要让类的命名空间与生成的持久性类型的命名空间相同。
using MyApp.Persistence;
public partial class Customer
{
public string FormatedAddress
{
// I now have access to all the generated members because
// I'm extending the definition of the generated class
get
{
return string.Format( "{0}\n{1},{2} {3}",
StreetAddress,
City,
State,
ZipCode );
}
}
}
【讨论】：
我会说设计模式完全取决于项目的规模以及您希望它如何“面向未来”。有多少用户会使用该软件？数据要被很多并发用户访问吗？当用户访问数据时，数据应该有多“最新”？
如果它是一个小项目，请保持简单，但允许您自己修改它，而无需更改整个应用程序。在较大的项目中，在决定设计模式之前提出上述问题很有用。
无论规模如何，至少创建以下单独的层都是有用的：
DAL - 仅负责更新和检索数据
业务逻辑 - 代表软件负责的流程的一组对象和方法（只有业务逻辑可以访问 DAL）
UI - 用于向用户呈现数据并根据业务逻辑获取用户输入（UI 引用 BL 层，只有通过其规则才能访问和修改数据）
通过这种方式，您可以修改任何层而不影响其他层，并且随着项目的发展，它会变得非常有用。
【讨论】：
在这里查看我的其他答案：
基本上 MVC、WinForms、WPF 或任何你有的表示层，我描述的分层仍然有效。
您的数据访问层的真实形状可能会在内部发生变化，具体取决于您在其中使用的内容，例如 NHibernate、实体框架、除了原始/纯 SQL 访问之外根本没有 ORM，您所做的任何事情都受到限制并包含在其中，您如果您最多从中抽象出来，并且您的所有其他层都被设计为独立于它，那么您将拥有美好的生活。
【讨论】：