我想知道我应该如何构建我的项目。
我们有一些项目在其他项目中(重新)使用。
我的意思是,我们的数据项目和模型项目用于一对多的其他项目。
我真正知道的是如何构建这种类型的项目,最好的命名方式是什么?
在标准的 3 层应用程序中,应该类似于:
- DAL、DataAccessLayer、数据...
- 模型、业务对象、BOL ...
- 用户界面,视图,...
还有其他想法吗?
在我工作的每家公司,他们都有不同的组织方式,有没有比另一个更好的?您使用哪一种,您更喜欢哪一种,为什么?
谢谢!
我想知道我应该如何构建我的项目。
我们有一些项目在其他项目中(重新)使用。
我的意思是,我们的数据项目和模型项目用于一对多的其他项目。
我真正知道的是如何构建这种类型的项目,最好的命名方式是什么?
在标准的 3 层应用程序中,应该类似于:
还有其他想法吗?
在我工作的每家公司,他们都有不同的组织方式,有没有比另一个更好的?您使用哪一种,您更喜欢哪一种,为什么?
谢谢!
这几乎就是我所做的,除了我有几个库项目我尝试放置我所有的可重用代码。然后我的模型和 DAL 位于这些库之上,只是向它们添加项目细节。
对于数据层,我通常使用:
Company.ProjectName.Data(即 AdventureWorks.OrderManager.Data)
对于业务层,我更喜欢“ObjectModel”之类的东西(我使用过“Business”或“BusinessLogic”,但这是数据在对象/类中聚集在一起的区域,所以为什么不这样命名呢?)。
Company.ProjectName.ObjectModel (即 AdventureWorks.OrderManager.ObjectModel)
对于 UI,我喜欢普通的旧“UI”或“Presentation”...
Company.ProjectName.Presentation(即 AdventureWorks.OrderManager.Presentation)
大多数情况下,我使用 Microsoft Patterns & Practices Application Architecture for .NET: Designing Applications and Services中推荐的分层架构。文档描述了实现它的体系结构和 .NET 技术。
软件架构取决于要构建的软件类型。如果您想进行内核编程,则与进行应用程序开发相比,其他原则适用。当您要进行物理模拟、天气预报软件、软件 IDE 或编译器时,还有另一个原则适用。
我假设您想做应用程序开发。那么,您很可能希望围绕您要反映的领域来设计您的软件。但即便如此,也有很多选择。
为了更深入地了解这个大主题,我强烈建议阅读Domain Driven Design
和阅读.Eric Evans
Applying Domain-Driven Design and Patterns
Jimmmy Nilsson
我目前正在开发具有 3 层架构的前端 Web 应用程序:
它具有分层架构,应用层中的层有:
这只是一个示例项目结构,最终结果将取决于应用程序的类型。您可以在我对这个问题的回答中阅读更多关于包的划分和命名策略的信息。
您可以根据需要添加/交换/删除图层。例如,在 SOA 中,您可以在应用程序层或服务层之上放置一个 Web 服务层,以便 ESB(企业服务总线)可以连接到您的应用程序或服务。如果其中任何一项是不可能的或看起来非常困难,那么您就没有最佳的架构和设计。
在考虑您的项目结构并允许上述场景时,您想要的模块和组件的一些重要属性是:
您可以通过设计低耦合和高内聚来实现这一点。通过按功能/抽象级别对模块进行分组来选择分层架构是一个好的开始。在每一层内按功能进一步分组也有帮助。让每个更具体的层只依赖于更通用层的接口也减少了耦合。