Prism 模块化实践 [英] Prism modularity practices

问题描述

我正在学习 Prism，需要创建一个小型演示应用程序.我有一些设计问题.态度之间的差异可能很小，但我需要稍后将这些实践应用于大型项目，所以我试图提前考虑.

I'm studying Prism and need to create a small demo app. I have some design questions. The differences between attitudes might be small, but I need to apply the practices to a large scale project later, so I'm trying to think ahead.

1. 假设经典的 DB 相关场景 - 我需要获取员工列表，双击列表项可以获得该员工的额外信息:数据访问项目应该是一个模块，还是一个被访问的项目通过存储库模式更好的解决方案?当数据库不止一张表并提供有关员工、销售、公司等的信息时，大型项目呢?

1. Assuming the classical DB related scenario - I need to get a list of employees and a double click on a list item gets extra information for that employee: Should the data access project be a module, or is a project accessed via repository pattern a better solution? What about large scale project, when the DB is more than one table and provides, say, information about employees, sales, companies etc.?

我目前正在考虑将 DataAccess 模块用作独立模块，并已在基础结构项目中定义其接口及其返回类型 (EmployeeInformation).这意味着我的 DataAccess 模块和我的应用程序都必须引用 Infrastructure 项目.这是一个好方法吗?

I'm currently considering to use the DataAccess module as a stand alone module, and have defined its interface in the Infrastructure project as well as its return type (EmployeeInformation). This means that both my DataAccess module and my application have to reference the Infrastructure project. Is this a good way to go?

谢谢.

推荐答案

1. 一个模块是必要的，当它包含可以独立存在的应用程序的一部分时才有意义.这可以是应用程序的一部分，只有几个人需要或被允许使用，例如用户管理模块只允许管理员访问.但是您的数据访问层并不是通常进入模块的那种孤立的功能.最好将其放置在真正模块可以使用的公共程序集中.这里的问题是所有模块都依赖于这个 DAL 程序集，因此在设计应用程序时要记住更新 DAL 的任务(向下兼容).
2. 通常将广泛使用的类型驻留在公共程序集中没有问题.但这不是基础设施组装.顾名思义，基础设施提供服务以使模块协同工作.您的常见类型应该进入类似 YourNamespace.Types 或 YourNamespace.Client.Base 或 ...
3. 这是许多争论中的一个话题，但仍然不清楚(至少从我的角度来看).依赖注入的纯粹主义者说它应该只在初始化期间使用.实用主义者在他们的整个应用程序中使用 ServiceLocator.

这篇关于Prism 模块化实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！