Tag: design

如何改变设计，使实体不使用注射？

我已经阅读并开始意识到自己的实体（数据对象 – 用于JPA或序列化）注入其中是一个坏主意。 这是我当前的设计（所有相应的字段都有getter和setter，以及为了简洁而放弃的serialVersionUID ）。 这是父对象，它是实体组合图的头部。 这是我序列化的对象。 public class State implements Serializable { List cars = new ArrayList(); List planes = new ArrayList(); // other objects similar to AbstractPlane as shown below } AbstractPlane及其子类只是没有注入的简单类： public abstract class AbstractPlane implements Serializable { long serialNumber; } public class PropellorPlane extends AbstractPlane { int propellors; } public class […]

单一责任原则如何与贫富/富域模型相关联？

目前正在对从另一个团队接管的内容进行一些代码审查，并对使用SRP及其与贫血或富域模型（由Martin Fowler定义）的关系存在疑问。 丰富的域模型概念是拥有智能对象，不仅可以设置/获取其属性，还可以执行更复杂的业务逻辑。 我喜欢它如何融入SRP？ 假设我的模型类有一些属性可以暴露这些道具并提供一些简单的计算。 下一个要求是有可能将此对象数据存储在一些不受我控制的存储对象中，如下所示： class MyObject { // get set // parse sth } 存储方法存储 storage.store(key, object); 如果MyObject具有这样的存储方法，它是否违反了SRP public void store(Storage storage) { storage.store(‘keyOne’, fieldOne); storage.store(‘keyTwo’, fieldTwo); } 从这个对象的pov来看，能够存储其状态是一个很好的想法。 其他方式可能是在这里介绍一种服务，并这样做： public StorageService { private Storage; // constructor here …. public void store(MyObject myobj); } 你能指点一下我能读到的关于这个问题的链接吗？ 我在这里找到了一个关于SO的post，但它没有完全回答我的问题。 如何在DDD中解决？ 根据定义，DDD中的模型很丰富，可以看作具有太多责任。

在业务逻辑和数据层看似重叠时分解的最佳设计？

我正在构建一个MVC Web应用程序（使用Spring MVC框架），我对设计特定区域的最佳方式感到有点困惑。 应用程序必须与一系列Web服务进行交互，这些Web服务并非真正设计得非常完美，并且本身并不提供很多抽象 – 基本上每个创建/更新/检索/删除操作都有一个Web服务方法。每个“数据类型”，除此之外没有太多的API。 Web服务客户端需要知道要调用哪些方法，以及能够以何种顺序创建所需的数据 – 换句话说，没有基于“事务”的方法。 例如，只需创建一个新的用户帐户，就需要调用总共七种不同的Web服务方法来设置必要表中的所有记录（ user记录，为该用户添加正确的privileges ，设置用户的billing明细等）。 我正在努力解决这个问题的最佳方法并将其封装在我们的应用程序中。 大多数应用程序遵循标准流程： request —> Controller Service/Business-level object DAOs for data access 在我的应用程序中，我使用自己的一组“域对象”来表示和抽象Web服务WSDL中定义的数据类型，这样我的域逻辑就不依赖于Web服务类型，因此我们可以抽象和隐藏我们喜欢哪个细节。 我正在寻找一些意见是设计上面提到的“用户创建过程”的最佳方式。 创建“常规用户”的过程涉及调用七种不同的Web服务，正如我所提到的，但这只是用户的一种“类型” – 我们必须能够创建几种不同类型的用户，每种用户都需要不同的要调用的Web服务。 目前我只是设计了这个“常规用户”创建，作为一个概念certificate – 我有一个域对象User ，一个UserDao接口，它有getUser(name)和createUser(User) ，以及一个WebServiceUserDao ，实现UserDao方法并知道如何调用上述七种Web服务方法。 createUser()方法由UserCreationService调用， UserCreationService是我的业务/服务级别类，而后者又由SignupController调用。 但是要扩展这个逻辑以便能够创建不同的用户类型（由User.getType()的不同值表示，我不确定在业务/服务层类和DAO之间绘制线的位置。例如，我应该： 每个“用户类型”创建一个UserDao实现，因此创建每个“用户类型”的逻辑可以封装在它自己的类中，让UserCreationService决定使用哪个UserDao ？ 这将对应于1个服务类：许多DAO。 我是否应该将UserDao分解为更小的部分，一个对应于需要在Web服务/ DB中创建的每个“记录”，即使我的整个应用程序不需要知道这些单独类型中的每一个？ 然后为各种不同的“用户类型”提供不同的UserCreationService实现？ 换句话说，即使我不需要相应的Privilege或BillingPlan域对象，此策略也会有PrivilegesDao ， BillingPlanDao等。 这将是许多服务类：许多DAO。 包含在单个WebServiceUserDao为每个“用户类型”调用Web服务的所有逻辑？ 这将有一个非常复杂的类的缺点（PMD已经在抱怨圈复杂度），但所有这些逻辑都将封装在一个类中，从整体API角度来看可能会减少复杂性。 我对此应用程序的一个目标是确保如果我们必须更改数据持久性的细节，我们需要做的就是更改DAO实现 – 如果我们必须开始与不同的计费系统连接，除了在DAO级别，我不希望应用程序的任何部分发生更改。 任何意见？ 在决定何时分解“业务逻辑”与“数据访问逻辑”时，您使用什么样的策略？

Java Enum可以有行为吗？

在Java中，Enum可以完成Enums所做的伟大事情，但也可以拥有方法（行为和逻辑）。 与使用枚举的类相比，它有什么优势？ 举例说明这一点也很受欢迎。

如何在“会话”中为所有bean提供状态？

我有以下设计。 当客户端向服务器发出请求时，服务器会创建一个包含各种信息的状态。 有各种无状态和有状态的bean需要读写这个状态。 请参阅此非专业图表： ComputationCycle类是处理开始并按阶段工作的地方。 在每个阶段，它调用其他Manager类（其行为类似于实用程序类）来帮助计算（图表仅显示1个阶段）。 正在从CC类和管理者那里读取和写入状态，两者都是无状态的。 State拥有有状态的Employee ， Department和Car类（在一些不相关的数据结构中）。 这些类也可以调用Manager类。 这是由一个简单的@Inject Manager1 。 CC使用经理的方式相同。 我的问题是如何从无状态类（以及Car ， Department和Employee类）访问有状态（及其包含的类），尽管我认为解决一个将解决另一个问题。 我无法将有状态bean注入无状态bean。 因此，在客户端发出请求并开始计算周期后，如何访问与此请求相关的状态？ 一种解决方案是将状态传递给无状态类中的每个方法，但这实际上非常麻烦和臃肿，因为所有方法都会在任何地方都有一个“愚蠢”的状态论证。 我怎样才能使这个设计按照我想要的方式工作？

Spring / Java中的调度任务

我正在产生一个线程，它将继续从数据库中提取大量记录并将它们放入队列中。 该线程将在服务器负载上启动。 我希望这个线程始终处于活动状态。 如果数据库中没有记录，我希望它等待一段时间后再次检查。 我正在考虑使用spring任务调度程序来安排这个，但不确定这是否正确，因为我只希望我的任务启动一次。 在Spring中实现这个的好方法是什么？ 此外，我需要进行边界检查，如果我的线程发生故障（由于任何错误或exception情况），它应该在一段时间后重新实例化。 我可以通过使用线程通信方法在java中完成所有这些，但只是尝试在Spring或Java中有可用于此类场景的东西。 任何建议或指针都会有所帮助。

是否可以一起使用DDD和BDD？

我喜欢用DDD实现的中间开发。 开发是由域，应用程序中最可靠的部分驱动的。 我们不依赖于基础设施，持久性和演示。 听起来不错。 但它没有商业价值。 这是以业务为中心的BDD与外部开发。 我们没有前期域设计（选择实体，值对象，聚合）。 我们收集用户故事，编写一些场景并逐个实现。 我们从应用程序的最多变的部分开始开发 – 从演示开始。 我讨厌写脆弱的验收测试。 你呢？ 所以，如果有人在这里有关于在BDD风格中应用DDD的成功故事，请与我分享一些:) 你是否为了演示而编写那些脆弱的测试？ 在为实现的用户故事创建域的一部分之前，您是否预先设计了一些设计？ 或者你在实施故事后重构DDD模式？ 任何帮助将不胜感激。 谢谢！