I have a question for you.
In the BCED approach, whe have 4 package (Boundary, Control, Entity, Database), in which there are many classes with some responsability. Who is responsible to istantiate and destroy objects in the Entity package? Control's objects or Entity's object?
I'll explain better.
For example, we have 1 controller class and 2 entity classes, linked to each other by an association. Suppose that we have to use the 2 objects of 2 separated classes in the entity.
So, the controller class istantiate both object of the entity like this:
//In the controller:
create_objects(){
Entity1 e1=new Entity1;
Entity2 e2=new Entity2;
}
or the controller istantiate only the first class object that instantiates, in turn, the second class object (I remember to you that the entity classes are linked!!), like this:
//In the controller:
create_objects(){
Entity1 e1=new Entity1;
}
//In the Entity1:
create_object_2(){
Entity2 e2=new Entity2;
}
Thank you in advance and sorry for the English! :)
BCED is an architectural view at the Model-View-Controller Pattern.
And in the last there is a principle: In Model/Entity or in View/Boundary layers the components are independent on each other. All interdependence is in the Controller layer. So, the classic behaviour is the first one - when you create both Entity classes from controller.
But classes are not components. And on this abstraction level the rule is far from being so strict. For classes take it not as a rule, but as a nice target: try to keep your Entity classes being more independent on each other.
But if you have an Entity1 that is a composition of Entity2 class with something else, then the second variant is the only sensible one.
Related
I am trying to implement the UML class diagram for the first time. This is the class diagram which I have been work through:
This is the requirement:
I do not expect anyone do it for me, but I think I need someone help to check where I can improve or I anything is missing. Thank You.
A class diagram is a structural diagram. Behaviors (e.g. adding, deleteing, etc...) shall not appear therein, except if you decide to make them operations of one class.
Here how to understand the requirements:
R1. Classes GroceryList, Item and User. Association between 0..n GroceryList and 0..n Item. Association class with property Quantity
R2. Class ItemType
R3. Association between 0..n Item and 1 ItemType. Both classes have a property Name
R6. Association class also has property CheckOff
R10. Association between 1 User and 0..n GroceryList. GroceryList has a property Name
Assumption: User has a property Name
If your teacher never told you what an association class is, then use a class ListItem instead, with an association of 0..n ListItems with 1 Item, and a coposition link from GroceryList to ListItem
Remove any other box in your diagram, because these are either behaviors, or a duplicate of an existing class.
For the operations, it is not clear to me because it depends on the architecture of your application (e.g. will you use repository classes?).
I need to apply business rules in a DTO, but this DTO has properties of N entities.
I wanted to know the correct way to validate this DTO.
Very common approach would be to wrap DTO into an Entity and implement business rules inside the Entity.
var state = new DTO();
var entity = new Entity(state);
//this will change the state in a consistent way according to business rules
entity.DoSomething1();
entity.DoSomething2();
//this is C#, so I can't get immutable version easily, but if your language allows that - you should return immutable state from entity. Or you can return a clone of the state
state = entity.State;
//store or do whatever you like with the state as long as you keep it immutable.
_repository.Save(state);
As DTO is just a data-transfer-object, it should never apply any business logics inside.
DTO has properties of N entities
The preferable way is to create an aggregate class for your case and apply business logics inside.
public class Entitity1
{
}
public class Entity2
{
}
public class EntityAggregate
{
public EntityAggregate(Entity1 entity1, Entity2 entity2) // constructor
{
this.entity1 = entity1;
this.entity2 = entity2;
}
public ExecuteYourBusinessCase()
{
... access entity1 and entity2 here and evaluate business logics
}
}
Also it's worth metioning that one of DDD ideas is to prevent creating of invalid objects. So your should guarantee that if domain entity has been created it is valid and DTO can always be created. Business logics remains a black box for the layer responsible for DTO creation
As already stated in other answers:
You shouldn't have business rules in your DTOs.
Although, when the topic is DDD, another very common approach to ensure that you'll always create valid domain objects is to use the Builder Pattern.
This pattern allows you to vary a product's representation. For example, a software may have a domain denominated Product, but - in real world representation - it may be a Service or a Material (I can sell a cellphone or a cellphone insurance), so two builders must be created (MaterialBuilder and ServiceBuilder, for ie) that builds the same domain object, the Product.
This pattern generally is used with a method chaining and leads to a fluent interface.
I am currently trying out DDD and reading Evans book. I have arrived at a model that has an aggregate whose root is Student. Now I need to have (or be able to distinguish) a RegisteredStudent and an EnrolledStudent (inherits RegisteredStudent). I don't know how to handle inheritance in DDD.
Should the 2 inherited classes be inside the aggregate? If so, are they also considered aggregate roots since their identity is the same as the root (there are only added properties to them)? If not, how do I give access to them from other entities?
Or should I not be using inheritance? Why?
And also, what if you have an entity in an aggregate that isn't a root, but you need it to inherit an entity outside? How should you go about it?
What you need to ask yourself here is whether a RegisteredStudent and an EnrolledStudent are different concepts. Are they not both students, but just in a different state?
In general, you should favor composition over inheritance.
Here's an example of what I would do. (Note that it's just my example, I don't know the domain, so it's not a definitive solution).
You could have a Student class, which is your aggregate root and then a few different state classes: Registered and Enrolled. That way you don't need to expose these state classes on the student but you could just expose methods on the Student. A small example in C#:
class Student
{
State _currentState;
void Enroll()
{
if(!_currentState is Registered)
throw new InvalidOperationException("Cannot enroll student who is not registered");
this._currentState = new Enrolled();
}
void Register(string name)
{
this._currentState = new Registered(name);
}
}
class StudentState{}
class Enrolled : StudentState
{}
class Registered : StudentState
{
public Registered(string name)
{
Name = name;
}
public string Name {get; private set;}
}
This is a simple application of the State design pattern, you could externalize more parts of it and build a complete state-machine, but I'll leave that up to you. (Also it's typed directly in to the SO-editor, so there could be syntax errors)
EDIT after comments
Whether you need to expose a State-property or not depends on the context. In general I would recommend not to do that, because you're exposing the internals of the Student. It would be better to expose a method called CanEnroll for example. That way you can change the internal implementation of your state pattern without affecting any clients.
As for question 3, it's hard to say without a use case. However, here are some guidelines:
Favor composition over inheritance (again, I know).
You can have a reference from inside an aggregate to the outer world, you shouldn't have a reference the other way around though.
Is there a bulit-in way to obtain an entity name from the class object of an NSManagedObjectSubclass? I know that this can be readily determined from an instance of a subclass, but I want to ask the class itself. I can write a class function, but I would rather do this introspectively.
You can do it now by executing NSManagedObject.entity().name where NSManagedObject() is your subclass.
Check out mogenerator if you haven't already.
http://raptureinvenice.com/getting-started-with-mogenerator/
It adds a lot of missing features to core data. In particular it keeps you from having to regenerate your entity classes.
You could iterate thru the key values of the entities in the context:
[managedObjectContext registeredObjects];
If you've got a function like this inside a class called 'A'
public updateResponse(UpdateRequest updateRequest){
//...
}
Where UpdateRequest is another class which you create an object from
as in UpdateRequest ur = new UpdateRequest();
What is the relation between those two classes (Between 'A' and 'UpdateRequest')? I thought of an "usage" link between the interface of A and the class UpdateRequest. Is this correct? If not, what kind of link should it be?
If the diagram is a class diagram there is no relationship to be taken from your question.
The relationship between these two classes would be best show in a Sequence Diagram or an Activity Diagram. These show method calls etc, a method may be a member of a class in a class digram but it wouldn't really be expressed as a link. Unless you specifically wantto highlight this method, you could then put a usage link to the method on the class. But its not always good practice to do this for every method as you end up with a very messy class diagram.
It's always best to show these relationships in the diagrams you have to show the usage of the method.
EDIT:
How does the class A instance relate class UpdateRequest instance?
Q - What relationship are you trying to show? A - Method/function call.
Some class calls updateResponse and the information flow is an UpdateRequest instance.
Therefore... From left to right
SomeClass --| A
| | a = new UpdateRequest |
|<-----| |
| |
| updateResponse(a) |
|------------------------------------>|
Your sequence diagram might look something like this. There is no specific relationship drawn between class A and UpdateRequest as it is simply a piece of information that flows through the method call you have in your example. If the class was a member of the class, then the relationship would be shown directly on a class diagram, not applicable here. All the classes might (should) shown on a class diagram seperately, this can then be used as a reference point about all the objects in any diagram for those that need to analyse the design.