2010-05-23 67 views
0

对于C#我还是比较新的,我正试图确定构建新程序的最佳方式。这是我想要做的,我想反馈我的想法。设计布局/模式

  • 表示层
  • 业务层(单独的类库)
  • 数据层(单独的类库)
  • 模型层(单独的类库)

什么我挣扎是如果可以让数据层和业务层中的类继承我在Model Layer中定义的类型。通过这种方式,我可以根据需要在我的业务层中扩展类型,并使用任何我认为合适的新属性。我可能不会在我的业务层类中使用模型类型中的每个属性,但这真的是一个大问题?如果这还不够清楚,我可以尝试一个例子。

+0

从你的名字我会猜测这是一个WPF应用程序,是正确的? – R0MANARMY 2010-05-23 03:37:34

+0

你是对的。 – user337816 2010-05-23 03:44:01

回答

5

一般的做法是使用的封装,而不是继承,用于图层转换。考虑以下两种范式(如果我理解正确)

Model/Data Layer: 
    Customer 
    Order 

Business Layer: 
    MyCustomer : Customer 
    MyOrder : Order 

Model/Data Layer: 
    Customer 
    Order 

Business Layer: 
    MyCustomer (encapsulates Data.Customer) 
    MyOrder (encapsulates Data.Order) 

有去第一(继承)路由时两个主要问题:

  1. 当你修改基础(数据/模型)类,你不得不改变业务类。
  2. 获取对象关系很困难,通常需要非多态的方法。 I.E.如果模型或数据层在Customer对象上公开了一个集合Order,那么让类MyCustomer暴露一组MyOrder对象变得困难而且“笨拙”。

利用封装处理这两个问题,绝对是我推荐的路线。看你的名字

,我假设你正在寻找写一个WPF应用程序。如果是这种情况,请查看Model-View-ViewModel (MVVM)设计模式。

+0

你几乎击中了头部。因为我对这个还是比较新的。我理解关于房地产的封装概念,但我不认为我理解它在这种情况下如何适用。你能再详细一点吗? – user337816 2010-05-23 03:50:44

+0

+1为跨层封装的核心概念。 – 2010-05-23 04:03:06

+0

针对MVVM的+1。 @wpfwannabe,我挣扎了几个星期学习MVVM直到我看了这部影片:http://www.lab49.com/files/videos/Jason%20Dolinger%20MVVM.wmv 我真的建议你给它一个看你做了之后玩了WPF一段时间。祝你好运! – bufferz 2010-05-23 12:15:14

0

我认为一个例子会很好 - 我不认为你的建议是必然不好,但这取决于你想要达到的目标。

你为什么要继承模型层中的类?什么是特定模型类的接口和目的,以及从模型类继承的业务逻辑类的目的是什么?

继承是否真的有意义?

继承会违反Liskov的替代原则吗?

编辑:

wpfwannabe,我会小心使用继承,只是因为它似乎是容易的选择。我特别提到了Liskov替代原则,因为它涉及确定何时继承是有效的。

另外,你可能也想看看“SOLID”的设计原则OO开发(包括里氏的替换原则):

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

+0

在这个例子中我的模型层将包含具有代表性数据库表的类型。简单的包含属性和构造函数的类。我想从业务层的模型类继承将是一个好主意,所以我想有我所有的基本属性,并根据需要,我可以创建新的。 – user337816 2010-05-23 04:01:56

0

是否把每一层的阶级独立的库取决于您是否需要写在未来将需要使用这些相同的类更多的应用。你可能会认为你需要马上开始做。根据我的经验,编码后至少有某种概念证明,我开始有更好的想法。在项目中期的某个时刻组织代码,比如重新分解,组织成图书馆等,很容易。它试图在上线之前这样做,这是危险的,而不是一个好主意。

关于你的问题的其余部分,我要提到你,我从Martin Fowler的教训,我不能说比他更好,如果我这样做,我只是跟着他重复:

http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/