I am trying to implement an UML Class Diagram and I would like to use an interface classifier CreateItem to inform a developer that (that rappresents an input web form), in order to populate an attribute TitleI in a class Item, he/she MUST use one or more TitleO of a class Object. That is, I would like to indicate that using a web form CreateItem you can "compose" a Item TitleI (TitleI is a string) exclusively searching and adding to it one or more Object TitleO (TitleO is a string).
It should working as "composing" the StackOverflow Tags "string" when you Ask a new question. The only difference is that I would like to create a Title string made by those Tags.
I "learned" to solve part of my issue in thinking this way:
< < interface > > **CreateItem** is a *realization* of **Item**
Then?
You can depict the composition/aggregation using respective relationships. You can use the dependency relationship to depict creation. If this doesn't help, try to formulate your question in other way or to be more precise and I will try to answer.
Related
I am trying to figure out what class Meta: really do in Django.
I come across with the code below in DRF, but not sure why under class Meta: there is model = User and fields = [...]. Does it help to create a database?
from django.contrib.auth.models import User, Group
from rest_framework import serializers
class UserSerializer(
serializers.HyperlinkedModelSerializer):
class Meta:
model = User
fields = ['url', 'username', 'email', 'groups']
And also what is the different with the class Meta: used in Django as below.
from django.db import models
class Ox(models.Model):
horn_length = models.IntegerField()
class Meta:
ordering = ["horn_length"]
verbose_name_plural = "oxen"
I have tried to get further understanding from both Django and DRF documentation however I did not see the explanation for model = ... and fields = [...] used in DRF class Meta.
Hope someone could help to explain the functioning principle behind. Thanks!
The Meta class is merely a convenient place to group metadata (meaning data about the data) that DRF needs to adjust its configuration, but keep this separate from the attributes of the class itself. This separation allows the Django Rest Framework (and the wider Django Framework ecosystem) to avoid clashes between configuration and the actual class definitions.
The use of an inner Meta class is a common pattern throughout Django, because this allows you to both keep this configuration separate from the fields of the class and keep it connected to the class in a way that's easy to read and easy for the framework to find. A DRF selialiser class should normally have one or more fields to help turn data into a serialized form, but the HyperlinkedModelSerializer base class can generate these fields for you if you tell it what model you wanted to serialise. The fields on the Meta class tell it you want to serialize specific fields from your User model.
By putting this configuration on the inner Meta class, they are kept in a separate namespace from the main class, but at the same time remain connected to the class they are meant to configure. Imagine a model that has a field named model and fields for example. If the HyperlinkedModelSerializer required that configuration is found in the subclass itself, you could never produce a serializer that could process something with model and fields fields!
If you wanted to know what the different options are you can use on the inner Meta class, you need to read the ModelSerialiser and HyperlinkedModelSerializer documentation in the API guide section.
For Django Models, you can refer to the Model Meta chapter of the Django documentation. As I stated above, it's the same concept but here the Meta class configures the database fields that the model supports and how the model relates to other database models you may have defined.
Last but not least, there is another answer here that confuses the term Meta with Python Metaclasses, which is a very different concept. While DRF and Django model classes lean heavily on metaclasses for their internal implementation, the class Meta: definition you use to configure the framework functionality, they are not metaclasses. They are plain classes that are only used because they make for a convenient namespace.
class Meta is used in DRF serializers to configure your serializer.
model defines the model to which your serializer is linked.
fields is a list of properties that you would like to serve in your API.
Use fields = ['__all__'] to serve all properties
Use exclude = ['your_excluded_prop_1', 'your_excluded_prop_2'] to exclude properties
The concept of Meta class comes from metaprogramming. The term metaprogramming refers to manipulating itself. Python supports a form of metaprogramming for classes called metaclasses. Meta class is mainly the inner class of your main class. Meta class is basically used to change the behavior of your main class attributes. It’s completely optional to add a Meta class to your Class. But in your Django project, you have already seen this metaclass concept available in different places like models.py, serializers.py, admin.py, etc.
Actually, this Meta class changes the common behavior of its main class like the model metaclass changing behavior using verbose_name, db_table, proxy, permissions, ordering etc, and a lot of other options. Meta class in serializer also does the exact same things it tells it the model to use and what fields to serialize by using fields, exclude, and model.
Good Luck :)
I'm a beginner in MVVM architecture and I'm stuck on an issue in a product app.
The issue: Mapping a Model to an Entity
Let me explain my code structure;
Domain > Respository > order_repo.dart
This order_repo.dart is an abstract class OrderRepo that declares a function getOrders that returns OrderEntity.
Data > Repo Implementation > order_repo_impl.dart
The order_repo_impl.dart contains a class OrderRepoImpl that defines the function getOrders that returns OrderModel that extends OrderEntity.
Domain > Usecase > order_usecase.dart
The order_usecase.dart contains a class that uses OrderUsecase that uses an instance of OrderRepo to call getOrders. Both the getOrders and call functions return OrderEntity.
The problem is that when I call the usecase, I expect it to return OrderEnity but the runtimeType is OrderModel. I tried to parse it as OrderModel but I could not do that because I get this warning, Unnecessary Cast, because at compile time the compiler is also expecting OrderEntity.
One solution I found is to define a Translator, that would convert OrderModel to OrderEntity inside usecase, but I'm confused regarding the right place for its definition, because I cannot use OrderModel inside the Domain layer as per Clean Architecutre to keep Domain independent of other layers and if I define the Tanslator inside Data layer, I still cannot call it in the usecase, because of the same reason.
It is bad practice
The order_repo_impl.dart contains a class OrderRepoImpl that defines the function getOrders that returns OrderModel that extends OrderEntity.
Not always model can extend entity f.e. (Code-Generated Model)
The domain layer should not know about implementation and about the data layer, because Implementation can change but Business logic will not as long as there is no changes in business logic.
I found is to define a Translator that would convert OrderModel to OrderEntity inside usecase
It is good practice
It is good practice to convert it inside implementation of repository. Because, repository is kind of binding between domain and data layers,
Or even, You can create converter class that translate entity to model and vice verca and the instance of the class will be to the constructor of repository implementation.
Why it is better to follow these advices.
Implementation quite often can change but abstraction rarely changes.
Easy to switch from one implementation to another one.
You follow SOLID principles
P.s. I hope I could answer to your question. Whether you have feel free to ask it on comments
I use Enterprise Architect for code generation and I would like to automatically retrieve all tags (in my case Java annotations) of the interfaces that a class realizes. Consider the following example:
From this model, I want to generate a class that looks like this:
#AnnotationOfMyInterface
public class MyClass {
...
}
So I want to add annotations as tags to MyInterface that should be applied to MyClass during code generation. In the UI, tags of implemented interfaces are shown so I was hoping there is a way to get these tags during code generation.
I tried to edit the code generation templates and found macros to get
All interfaces that a class implements: %list="ClassInterface" #separator=", "%
All tags with a given name (of the class that code is being generated for): %classTag:"annotations"%
But unfortunately, I cannot combine these macros, i.e., I cannot pass one interface to the classTag macro so that I can retrieve the tags of that particular interface (and not the one I'm generating code for). Is there a way to get classTags of a specific class / interface?
I also tried to create a separate code generation template and "call" it from the main class code generation template. But inside my template, the classTag macro still only gets the tags of the class.
Thanks to the comments above and especially because of an answer to my question in EA's forum, I was able to setup a little proof of concept achieving what I wanted. I'm answering my question to document my solution in case someone has a similar problem in the future.
After Eve's hint in EA's forum I looked into creating an AddIn for Enterprise Architect to use this AddIn from a code generation template. I started by writing a basic AddIn as explained by #Geert Bellekens in this tutorial. Afterwards I changed the AddIn to fit my needs. This is how I finally got the tagged values (annotations) of the interfaces a class realizes:
First step:
Inside a code generation template, I get all the interfaces a class realizes and pass them to my AddIn:
$interfaces=%list="ClassInterface" #separator=", "%
%EXEC_ADD_IN("MyAddin","getInterfaceTags", $interfaces)%
Second step:
As documented here the repository objects gets passed along with the EXEC_ADD_IN call. I use the repository object and query for all interfaces using the names contained in $interfaces. I can then get the tagged values of each interface element. Simple prototype that achieves this for a single interface:
public Object getInterfaceTags(EA.Repository repo, Object args)
{
String[] interfaceNames = args as String[];
String firstInterfaceName = interfaceNames[0];
EA.Element interfaceElement = repo.GetElementsByQuery("Simple", firstInterfaceName).GetAt(0);
String tag = interfaceElement.TaggedValues.GetAt(0);
return interfaceElement.Name + " has tag value" + tag.Value;
}
I know, there are a couple of shortcomings but this is just a simple proof of concept for an idea that will most likely never be production code.
This is more of a generalized question as I have yet to write the code for the question I am asking. Before I get started writing the code I wanted to make sure I am on the right track and possibly getting suggestions for better ways to do what I want to do. Basically right now I have a core data model setup in a way that I think is correct for what I am trying to do and just need some guidance on a very specific part of the code but want to make sure overall I created it correctly.
The first part to the question is more of a clarification on how relationships work in core data. Right now I have 5 entities and to make sure I have the correct idea on how it works I will use a few examples to make sure I am on the right track.
So lets save I have an entity I called name. Within that Name entity that contains only a name attribute. Next I have an entity that has classes, that each have a boolean of true or false to determine which class it is. These 2 are related in a inverse relationship of Name entity having a to one relationship and the Classes having a to many relationship because multiple names can have multiple classes but each name can only have 1 class. If I am right on this one that means I full understand core data relationships!
Now the second part of the question is related to the booleans in the class. I have the Class entity which is like I said a boolean containing a true false set as default to false. When the user selects one of the class buttons before presenting the popover where they actually give the name of the class selected it saves the boolean to true then passes that data over to the popover Name view controller. I am very unsure as to how to do this as it isn't a widely asked question on here nor have I been able to find any info through researching. I am one of those people who needs to actually learn by clear examples....any help with this would be appreciated! Sorry I don't have any example code for this.
The first part seems correct. The ManagedObject of your Class CoreDataObject should have an NSSet property which will contain the names (as the Class can have multiple names)
For the second part, Core Data uses objects. When you 'get' the data from Core Data it will be a (probably extended) NSManagedObject (named Class in our case). You can send this object as a parameter just as you would do with any other object and use it as you would use any other object :-). For example looping over de NSSet Names
func iterateOverNames(someClass: Class) {
for name: Name in someClass.names {
// do stuff
}
}
You can check these links for more information:
https://realm.io/news/jesse-squires-core-data-swift/
https://developer.apple.com/library/ios/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObject_Class/index.html
The title may seems confusing, but it's not easy to describe the question in few words. Let me explain the situation:
We have a web application project, and a calculation engine project. The web application collect user input and use the engine to generate some result, and represent to user. Both user input, engine output and other data will be persisted to DB using JPA.
The engine input and output consist of objects in tree structure, example like:
Class InputA {
String attrA1;
List<InputB> inputBs;
}
Class InputB {
String attrB1;
List<InputC> inputCs;
}
Class InputC {
String attrC1;
}
The engine output is in similar style.
The web application project handle the data persistence using JPA. We need to persist the engine input and output, as well as some other data that related to the input and output. Such data can be seem as extra fields to certain class. For example:
We want to persist extra field, so it looks like:
Class InputBx extends InputB{
String attrBx1;
}
Class InputCx extends InputC{
String attrCx1;
}
In Java OO world, this works, we can store a list of InputBx in InputA, and store a list of InputCx in InputBx because of the inheritance.
But we meet trouble when using JPA to persist the extended objects.
First of all, it requires the engine project to make their class become JPA entities. The engine was working fine by itself, it accept correct input and generate correct output. It doesn't smell good to force their model to become JPA entities when another project try to persist the model.
Second, the JPA doesn't accept the inherited objects when using InputA as the entry. From JPA point of view, it only know that InputA contains a list of InputB, and not possible to persist/retrieve a list of InputBx in object of InputA.
When trying to solve this, we had come up 2 ideas, but neither one satisfied us:
idea 1:
Use composition instead inheritance, so we still persist the original InputA and it's tree structure include InputB and InputC:
Class InputBx{
String attrBx1;
InputB inputB;
}
Class InputCx{
String attrCx1;
InputC inputC;
}
So the original input object tree can be smoothly retrieved, and InputBx and InputCx objects needs to be retrieved using the InputB and InputC objects in the tree as references.
The good thing is that no matter what changes made to the structure of the original input class tree (such as change attribute name, add/remove attributes in the classes), the extended class InputBx and InputCx and their attributes automatically synchronized.
The drawback is that this structure increases the calls to the database, and the model is not easy to use in the application(both back end and front end). Whenever we want related information of InputB or InputC, we need to manually code to search the corresponding object of InputBx and InputCx.
idea 2:
Manually make mirror classes to form a similar structure of the original input classes. So we created:
Class InputAx {
String attrA1;
List<InputBx> inputBs;
}
Class InputBx {
String attrB1;
List<InputCx> inputCs;
String attrBx1;
}
Class InputCx {
String attrC1;
String attrCx1;
}
We could use this as model of the web application, and the JPA entities as well. Here's what we could get:
Now the engine project can be set free, it doesn't need to bind to how the other projects persist these input/output objects. The engine project is independant now.
The JPA persistence works just fluent, no extra calls to database is required
The back end and front end UI just use this model to get both original input objects and related information with no effort. When trying use engine to perform calculation, we can use a mapping mechanism to transfer between the original objects and extended objects.
The drawback is also obvious:
There is duplication in the class structure, which is not desired from the OO point of view.
When considering it as DTO to reduce the database calls, it can be claimed as anti-pattern when using DTO in local transfer.
The structure is not automatically synchronized with the original model. So if there are any changes made to the original model, we need to manually update this model as well. If some developers forget to do this, there will be some not-easy-to-find defects.
I'm looking for the following help:
Is there any existing good/best practices or patterns to solve similar situation we meet? Or any anti-patterns that we should try to avoid? References to web articles are welcome.
If possible, can you comment on the idea 1 and idea 2, from the aspect of OO design, Persistence practices, your experience, ect.
I will be grateful for your help.