Many Java ORMs support embedded class mappings, i.e. a relationship to a SCO which does not have a life of its own and is embedded in the table of the parent class, but I cannot find how to do this with SQLAlchemy.
E.g. Human has a Head and the Head attributes get mapped inline in the Human table.
Is this possible with SQLAlchemy?
Related
I am working on a project with Xpages.I wanted to know how to make the representation of a class diagram to my project.Notes is a documentary database so no relationnal.How I could represent my entities?
In Domino, documents are merely evidence of the existence of people, processes, and physical entities (products, offices, inventory, etc.). Ideally, your classes should model those things.
For instance, you might have classes like Employee, with properties like firstName, lastName, hireDate; maybe Asset, with properties like category, model, serialNumber; or perhaps Request, with properties like status, requester, dateApproved. Eventually the values of each of these properties might be stored as item values in Domino documents, but defining these first as attributes of classes allows you to follow a simple pattern to develop your application:
Use your class structure to rapidly define the nature of each "thing" your application interacts with, without worrying yet what each must look like or how and where the data will ultimately be stored.
Once you have these classes defined, you can bind visual components on an XPage (such as input fields like edit boxes and radio button groups) very easily using the #{dataSource.propertyName} syntax.
When these two steps are done, all you have left to do is to add two methods to each of these entity classes: one to write the data, and another to retrieve it.
Following this approach makes it very easy to rapidly build the application, but also protects your user interface from changes in how you wish the data to be stored. Initially, each object might represent a single document. As the application grows in either complexity or adoption, however, you may decide to segregate the data such that many documents are created to represent a single entity. Or at some point you might even decide to store some, or all, of the data outside of Domino (DB2, SQL, etc.). If your XPage components are bound to properties of these entity classes, all you need to do to change how or where the data is stored is to update the two methods you created in step 3 of the above list: alter how you write and retrieve the data. Your actual XPage design elements don't need to change at all.
Depends how you look at it. You can always think of following relation: Notes Form <-> Java POJO and Notes View <-> Java Collections.
See http://www.pipalia.co.uk/notes-development/rethinking-xpages-part-two/ for some tips on using Java world standards when working with xPages.
After reverse engineering code first, I got entity classes and mapping. Most of the business classes (that I already have) have the same name as entity classes and most of the properties in entity and business classes are the same.
If I understand the implementation right, I should make partial classes with entity classes having all the properties and change the business classes by removing those properties and leaving only the business rules.
If that is correct, what to do about derived classes? Obviously entity classes need all properties from base class. Can I change the code in the entity classes so that the entity classes also inherit from the base classes?
Any thoughts would be welcome.
Perhaps you should remove your business classes. ORM is tool for loading and persisting objects - you don't have special set of objects for persistence and special set of objects for business logic. Use single set which consists of persisted properties and computed properties + business rules executed on persisted properties (store them in partial class). That will form something which is commonly called domain object - it has both data and logic related to its data. You can have separate classes performing logic on multiple domain objects (so the logic doesn't belong to the object itself). These classes are commonly called domain services.
are you saying that most of the properties in entity and business classes are the same ? It shouldn't be like that. Business classes should have only the business logic not the properties of entities. Business class will use entity classes to fulfill the business.
Here is a good example http://code.msdn.microsoft.com/ASPNET-MVC-Application-b01a9fe8/
I want to add browsable attribute to some properties for entities generated by LINQ to SQL.
Is it a good idea? Since these entities are auto-generated, and when I regenerate they (the attributes I have added) might be overwritten.
I would probably use Damien Guards LINQ to SQL T4 templates, and modify the template to include the attributes you need. Then the attributes will be generated when you regenerate the classes.
You cannot add additional attributes to the properties in another partial class file because you would be defining the property more than once. This is one reason, among others, that we created our own code generator that generates L2S entity classes the way we want them.
Our code generator also generates a second set of 'application' entities that are much more lightweight than the L2S entities and used at the application level. They contain no L2S plumbing, but do contain other characteristics that the application level finds useful.
My newly created system was created using the Model Driven Architecture approach so all I have is the model (let's say comprehensive 'Order' and 'Product' classes). These are fully tested classes that support the business of my application. Now it's time to persist these classes as objects on the harddrive and at some later time retrieve them in the same state (thinking very abstractly here). Typically I'd create an IOrderRepository interface and eventually a ADO.NET-driven OrderRepository class with methods such as GetAll(), GetById(), Save(), etc... or at some point a BinaryFormatter-driven OrderRepostiroy class that serves a similar purpose through this same common interface.
Is this approach just not conducive to LINQ-To-Sql or the Entity Framework. Something that attempts to build my model from a pre-existing DB structure just seems wrong. Could I take advantage of these technologies but retain this 'MDA' approach to software engineering?
... notice I did not mention that this was a Web App. It may or may not be -- and shouldn't matter.
In general, I think that you should not make types implementing business methods and types used for O/R mapping the same type. I think this violates the single responsibility principle. The point of your entity types is to bridge the gap between relational space and object space. The point of your business types is to have collections of testable behavior. Instead, I would suggest that you project from your entity types onto your business types when materializing objects from the database. Separating these two allows your business methods and data mappings to evolve independently, which is very important, especially if you cannot always control the schema of the database. I explain this idea more fully in this presentation.
In a class diagram, is there a way of specifying that a class is an internal class of another class ?
Or is it considered as a pure implementation choice ?
Consider using a nesting relationship (a line with a '+' in a circle at the parent end).
Since UML isn't supposed to be directly implementation specific, I'd use a naming convention, such as:
OuterClass vs OuterClass::InnerClass
I would imagine if you're hoping to reverse-engineer or code-generate to/from UML that different tools would us different techniques (if they support it at all).
A quick test of some reverse engineering using Enterprise Architect (EA v7) confirms that they use the above InnerClass::OuterClass syntax when processing some C# with a public inner class.
For this kind of thing you have separate Diagrams showing the internal structure or processing of a class.
usually, those extra diagrams are activity diagrams to show processing. Sometimes one per method. You might also have an internal sequence diagram showing the API interactions.
No reason you can't have an additional class diagram to show internal structure of a class.
Or you can show the inner class fully enclosed by the outer class, one rectangle inside another.