洋葱架构
我正在为即将推出的内部应用程序建立一个项目结构,该应用程序试用巴勒莫提出的洋葱架构(http://jeffreypalermo.com/blog/the-onion-architecture-part-3/)。
我遵循了他的指导方针,但是到目前为止我需要对项目的结构进行一些验证。
在图表之前,问题是:
我认为参考文献都是正确的(按照图表设置,其中箭头表示“有参考”) 但进行一些验证会很好。
我应该在依赖解析层中放置什么?这是哪里吗 帮手去吗?这引用了所有其他项目?
网络服务和网络服务如何进行? UI,与 DAL 通信? (通过核心?如何?)
什么应该去哪里? [我知道的广泛问题...]
简化的概念图如下(文件夹代表命名空间):
I am setting up a project structure for an upcoming internal application trialling the Onion Architecture proposed by Palermo (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).
I have followed his guidelines, however I need some verification on the structure of the project so far.
Before the diagrams, the questions:
I think the References are all correct (set up as per the diagram where an arrow means 'has a reference to')
but some verification would be good.What should I put in my dependency resolution layer? Is this where
Helpers go? This has a reference to all other projects?How do the web services & UI, communicate with the DAL? (Through the core? How?)
What should go where? [Broad question I know...]
The simplified conceptual diagram is as follows (Folders represent namespaces):
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
1 看起来不错,但我不确定将依赖关系解析插入到图中是个好主意。
2 我相信依赖注入的东西会在这里。
3 根据巴勒莫图,是核心。在核心中,您将拥有与 DAL 和域模型通信的存储库,以及处理存储库和域模型的服务(不是 Web 服务)。 UI/Web 服务主要与服务交互。
4 同样,我认为答案就在巴勒莫的图表中。但在我看来,当对架构有充分的了解时,组织项目可能会变得不同且琐碎。
一旦我理解了 DDD 和必要的设计模式(例如 MVC、依赖注入、存储库/服务、ORM),洋葱架构对我来说就变得显而易见了。
1 It looks OK but I am not sure it's a good idea to insert dependency resolution into the diagram.
2 I believe dependency injection stuff would be here.
3 It is core according to Palermo's diagram. In core, you will have repositories talking to DAL and domain models, and services (not web services) dealing with repositories and domain models. And UI/web services will mainly talk to services.
4 Again, I think the answer is in Palermo's diagram. But in my opinion, organizing projects can be different and trivial when there is full understanding of the architecture.
Onion architecture became obvious to me once I understood DDD and necessary design patterns such as MVC, Dependency injection, Repository/Service, ORM.
某种 IoC 容器解决方案。这不是助手的地方
类,期望用于解决目的的帮助类。
WebServices 实现了这些接口。在您将使用的 UI 内部
通过定义的接口实现 DAL 或服务。
正确的实施将通过帮助来解决
依赖解析组件(看看这个概念
“控制反转”或“依赖注入”)。
some kind of IoC Container solution. It is no place for Helper
classes, expect helper classes for resolution purposes.
WebServices implements these interfaces. Inside the UI you would use
the DAL or Service implementations through the defined interfaces.
the correct implementation would be resolved through the help of the
Dependency Resolution component (have a look at the concept of
"Inversion Of Control" or "Dependency Injection").