I'm developing a ER model and i have a trouble.
I have a entity called client and it pay for another client (Same entity)
It's something like this:
client(one,many) --- PAY-->(relationship) --- (one,many)client
that this right?
I thank those who help me.
P.S: Sorry for my bad english, i'm still learning...
Yes.
client(one,many) --- PAYS FOR-->(relationship) --- (one,many)client
is correct.
These relationships between the entities are called Recursive Relationships. It is similar to a manager paying an employee, as the manager is also an employee. Employee == Client in your case.
Do go through this site to get a detailed knowledge about relationships. http://www.sqa.org.uk/e-learning/SoftDevRDS02CD/page_49.htm
Related
Is it good practice to create a database from a domain model, using a code-first approach, which then dictates what the database schema looks like (using entity framework). Or should you always design the db first and then create you domain model(s)?
From 2009 to 2013-ish, that's exactly what I have done (and answered many SO questions doing exactly that!) - using Entity Framework as our "Aggregate Roots" and extended them from there with value objects (poco classes) and so on.
I am here today to tell you this: DON'T DO IT!
The latest "rutt-rough" coming from DDD in C# is how most of us have done this - a direct "Table to Entity/Aggregate" mapping. All this does is give a false sense of separation without any bounded contexts.
In the past, I usually created a folder called, say, "Users". I also had an entity called User.cs for code first (or in the designer, a table called User). I was allowed to add my own methods and properties onto a User.cs partial. I would also group all value objects related to users within a subfolder. So, it looked like this:
\Users\
^- User.cs partial with additional so called "logic"
- UserService acting with "business logic" on User and related properties.
\users\EmailTemplates\
^- I often needed a way in DDD to store other "Entities" related to this AR.
\Users\ValueObjects\
^- UserAddress.cs
- UserTarget.cs
- UserTypeEnum.cs
- // basically a dumping ground
Now, after a year, we've come to realize that we have so much work on UserTarget that it is huge. It is becoming a huge service-like class with 1000 lines of code. In DDD, this really should be it's own bounded context, called UserTargets and act as its own aggregate root, with many value objects in it. But yet, there isn't anything stored in the DB. Do we create a entity in code first? have an exception in attributes to ignore it? etc.
It just feels so dirty and hacky any way you cut it.
Let's take another example out of the DDD playbook:
Biz: "I have a user that needs to signup. Once they signup, they will have a project."
Dev team: "Great, we have the following entities: User and Project"
public class User {
public List<Projects> Projects { get; set; }
public Team Team { get; set; }
}
public class Team {
public List<Projects> Projects { get; set; }
}
public class Project {
public User Administrator { get; set; }
public List<User> Members { get; set; }
}
That alone is a problem. Now that we are using CQRS/event sourcing often, it's easier to model it more like:
User : AggreateRoot
Team : AggregateRoot
Project : AggregateRoot
UserProject : AggregateRoot
UserSignup : AggregateRoot
TeamProject : AggregateRoot
...etc
Note the additional aggregates? How would you represent them in the DB? FKs right? Well, what if there are additional properties like a TeamProject.ContestEntrySubmitted datetime? Ah yes, now those FK child tables get ugly in EF and code first.
The domain is for your pure business design - to solve solutions. Not for how many POCOs you can organize to make EF happy in code gen. Not as your CRUD layer to bypass all business logic, new up an ObjectContext, and call Save(new User()). I see developers wasting so much time with this or that EF issue, wrestling with "do we side-step DDD to make EF do this? or do we spent a few days changing EF's internals and T4s to do that instead? we'll remain DDD-ish, but many that's a lot of work."
So I am hear to ask, "Why do it at all?" Separate the domain from any storage model.
In CQRS, your "Domain" is write-only anyways. Having them as a EF objects already throws event sourcing out the window, and now forces you to handle states.
By freely writing domain aggregates and entities allows us to bind multiple projects, or users, to each other without affecting the other aggregates. if the other aggregates, say User, wants to have a project count, sure, listen for the ProjectCreated event for that userid who created it and ProjectCount++ and call in the day.
The point is, once you apply DDD to Event Sourcing patterns, you look at your domain quite differently. It is no longer a "stateful" domain in a sense that you can query anytime to get the last 10 years who signed up, or knowing you can just go to the DB and run that SQL. No, instead it is more like, "I need to make a state change to X entity. It will be caused by this, this and that when in these specific states. Now, when the planets have aligned, we'll change the Username to be this in a new ChangedUSernameBecausePlanetsAligned event."
I guess my point I am trying to make is going down the EF Entities-as-DDD AggregateRoots feels so dry in the end, and without any DDD substance. You end up with nearly 30 or 50 "aggreateroot" folders in your monolithic MyProject.Domain assembly. And is what Udi basically calls, a Big Ball of Mud.
My general rule now is not to use any frameworks for my domain - freeing me up to structure it in pure DDD as I see fit, and it has been really enjoyable. There are no confining frameworks or restrictions. I've actually re-written entire domains in F#, just for fun and since there was no need for any "queries", it just happened.
Then, wjem moving into the Event Sourcing world, you start to realize exactly why your domain is "write only" and think about how you can "push" data to the views, instead of giving the views something to query from your domain. Removing that Querying part from your domain really makes this nice and neat.
--
Eh, I think I just realized that I wrote an answer that basically says, "Hey, don't do Entity Framework and DDD. Check out CQRS and DDD instead." LOL
I am very new to creating ontologies, and I'm trying to make one for a club and society section of a website only using a few classes.
This is my structure so far (classes then indented for sub classes).
Person
Member
President
Treasurer
Club/Society
TypeOfClub
Community
CourseRelated
FaithAndCulture
HobbiesAndInterests
MediaArtsAndMusic
PoliticalAndActivism
Venue
Booking
Location
I'm not 100% sure if what i'm doing is right. I just got rid of a lot of my sub classes realising that they were data type properties (number of members, joining fee) so now I have very few sub classes and can't think of what to add in their place.
I have venue as separate from location because I was trying to add in an rdf file that dealt with location in protoge (just to see how it would work).
Is there anything I should definitely add/get rid of with my class structure?
I hope this documentation http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html will help you to get a basic idea about Ontologies
I am fairly new to using Rhomobile, however I am not fully understanding how the local storing works and how to use the Rhom API.
I've set up the RhoStudio and run the configurations.
What I am trying to achieve is basically have two data models (with property bags as default): one for wards, and one for patients so I can create patient and ward objects.
Eventually I would like to list the wards, and the patients that are assigned to the ward objects.
Can someone explain how I use the Rhom API to be able to achieve this?
I have ran a simulation so once I have something like: /app/Patient/{131199009368684.14}/show in the web inspector, so I am assuming that I will need to create an association of some sort.. And then filter it out with a group Query.
In my personal opinion using the RhoMobile Doc's are not helpful enough.
Many thanks if someone can give me a typical example.
Rhodes auto generates unique ids for each instance of a Module, when it is created. This property is called "object". "131199009368684.14" what you got is the "object" of a particular patient that you created. What you can do to link the patients to the ward is:-
Add an additional property to the Patient Model that stores the "object" of the Ward instance you want to link that particular patient to. Thus you will be able to list all the patients in a particular ward by running a find query on column that stores the object of the Ward in the Patient table, by supplying it the particular Ward's object.
Hope this is useful.
This is something that has been pulling at me for a while. Consider a (MVC type) web application with an ORM (e.g. Nhiberate) as the data access layer.
On one hand - the OOP/Rich domain model hand - I feel I should be passing around (references to) the real objects I am talking about.
On the other hand - the DB/Web App hand - I feel that it is easier and more efficient just to pass the integer Ids of the objects rather than the object themselves.
Consider an ecommerce catalogue type application:
The user is logged in and navigates to a product page.
They post a comment.
The controller action tasked with persisting this comment has 3 pieces of information: a) The user id (from the auth cookie or wherever), b) The product id (probably from the querystring), and c) the comment text.
Now, what what is best practice here? Is it really worth inflating the user and product objects (e.g. by getting them from the repository, with all the DB work that entails) when we know that all they will be used for is so the ORM can read their IDs and set the appropriate foreign keys in the DB table that stores the comments?
What are peoples views on this? Perhaps web apps should be given a little more leway than other apps, due to their stateless nature? I imagine there will be 'it depends' answers, but maybe some people are purists about the issue.
This is a general question which probably is applicable to many platforms, but if giving examples I would prefer them to be ASP.NET MVC if possible.
Thank you.
NHibernate has the load operation (as opposed to doing a get) exactly for this reason.
session.Save(
new Comment
{
Text = commentTextFromScreen,
User = session.Load<User>(userID),
Product = session.Load<Product>(productID)
}
};
In the above example, you are telling NHibernate: I know these already exist in the database, so don't bother selecting them right now. NHibernate will return proxy objects for them and a select won't happen against the database as long as you don't attempt to access any properties on the objects.
For more info check out Ayende's blog post: The difference between Get, Load, and query by id.
We have an ASP.NET MVC application. Is it correct to think of the models as the "entities" in the system?
Presumably this comes down to the "type" of model (view or domain) - and if they are domain models then they are equivalent to entities?
Edit: I ask the question to determine whether the introduction of the "entity" nomenclature into our project is useful, or confusing.
As far as I'm concerned, you nailed it. Your distinction between view and domain models is correct. A domain model can be considered equivalent to an entity.
To answer your second question, I don't think it is necessary to introduce the entity nomenclature into your project, but I don't think it would be too confusing if this is something you wanted to do. I typically move my domain models into a separate project. I use the stock Models folder to hold my view models
[EDIT]
Based on the comments below, I thought I would clarify one thing. Specifically in the context of the Entity Framework, a domain model encompasses more than your DB entities. For example, a Custom Type representing an Address (Address 1/2/3, City, State, Zip, etc.) would also be a domain model even though it isn't given the name "Entity" by the Entity Framework.
To paraphrase what wikipedia has to say on the subject, an entity is an object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.
My understanding is an entity's identity and uniqueness are its defining quality. No two entities can have the same identity.
An entity is a domain model, although a domain model may not necessarily be an entity. Vaulue objects such as credit cards, addresses, dates, currency, are (or can be) domain models also.