设计DAL /数据集/业务对象

我目前正在设计一个需要访问数据库（SQL Server）的应用程序（.Net WinForms）。设计DAL /数据集/业务对象

使用数据源向导，Visual Studio将自动创建行的数据集，表和类：

例如，如果我有Customers表向导将创建“CustomersRow”级，从Global.System.Data继承.DataRow与相应的字段作为属性。

在我的应用程序中，我需要为Customers类实现其他方法和属性。

如何处理这些生成的类，通过添加方法修改它们，或忽略它们并实现我自己的业务类？

第二个问题：

如何填充我的对象

你建议使用数据表/数据集和他们的方法或建立自己的数据访问层和我见面的客户端（例如客户名单？）（顾客）列表？

我在搜索网络时发现了一些模式，但它并不精确。

感谢

来源

2011-09-24 amine

我会说设计模式完全取决于项目的规模和如何“未来证明”你想要它。有多少用户会使用该软件？数据是否被许多并发用户访问？用户访问数据时应该如何“最新”？

如果这是一个小项目，保持简单但允许自己修改而无需更改整个应用程序。在决定设计模式之前，在更大的项目中询问以上问题很有用。不管规模的

是非常有用的创建至少以下独立的层：

DAL - 负责仅用于更新和检索数据

商业逻辑 - 一组对象和表示方法的过程软件负责（只有业务逻辑才能访问DAL）

UI - 用于将数据呈现给t他用户并根据业务逻辑（UI参考BL层，并且只通过它的规则访问和修改数据）接受用户输入。

这样，您可以修改任何图层而不会影响其他图层，并且随着项目的增长它可以变得非常有用。

来源

2011-09-24 14:08:49

我是新来的设计模式太多，但我认为最好的解决办法是把业务层上的生成类和DAL的顶部。然后在这个层中，你可以实现你的类的自定义方法和属性，也许你应该考虑使用POCO对象。

来源

2011-09-24 13:38:14 BigL

说到层和层，请保持简单。一些开发人员在业务层面上非常学术，但他们所做的只是增加了不必要的复杂性（请注意architecture astronauts）。所以我的第一个建议是保持简单和容易维护您的特定应用程序。

目标是在维护复杂性和灵活性之间取得平衡。您希望您的应用具有增长灵活性，而无需进行大量更改，但同时您希望能够获得易于理解的应用。

在持久性和客户端之间至少有一层是一件好事。这使您可以灵活地在客户端和数据库之间放置域和/或服务。除非你正在解决一个特定的问题，否则我不会超越这个范围。

至于从您的持久性加载，您可以使用部分类来扩展生成的持久性类。这是添加附加功能的简单方法，同时保持原始属性和方法的完整性。

如果您需要将持久性对象转换为应用程序使用的域对象，我建议将构造函数或静态创建方法放在持有对象的域对象上，然后将其转换为域对象。你可以做同样的事情回去持久。

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); 
     } 
    } 

}

来源

2011-09-24 13:48:14

看看我这里的其他答案：

MVC3 and Entity Framework

基本MVC，的WinForms，凡是你必须为表现层我描述的还是有有效的分层WPF或。

您的数据访问层的真实形状可能会在内部发生变化，取决于您在那里使用的内容，如NHibernate，实体框架，除原始/纯粹SQL访问外没有任何ORM，无论你做什么都是有限的，如果你从最多的层面抽象出来，你的所有其他层都被设计为独立于它，你将拥有美好的生活。

来源

2011-09-24 14:18:56

设计DAL /数据集/业务对象

回答

相关问题