I have an abstract base class Contact that has two subclasses: Person and Company.
I want to have a Customer, Vendor or other types that can be either a Company or a Person (all sharing the same primary key ContactId).
My question is if it's possible to inherit all these types from Contact? If the answer is no, is there another option of utilizing the Contact property from the PK? What's the recommended design for this scenario?
Note that I want an Employee/Customer etc. to also be able to be a User.
How would you achieve that in C#? That is the first question you must answer yourselves because .NET doesn't support multi-inheritance so you cannot have single Customer class derived from Person or / and Company - you need separate Customer class derived from Person and another Customer class derived from Company but every time you see this you should know that you are doing something wrong. Also if you in the future find that you need to have Contact which is both Employee and Customer you will be ready to delete whole your application because with inheritance there will be no way to achieve that. Changing Contact from Customer to Employee will be possible only with direct SQL because EF doesn't allow that.
Inheritance is not solution for your problem - you must use composition (relations).
Related
Hi, I have recently started to learn system analysis and design and am having some trouble understanding domain model class diagram (DMCD) association class.
As per image, when drawing the DMCD, I'd like to understand if an association class is allowed to contain attributes of the classes it derives from. The Invoice needs to contain the attributes apptNo and svcName.
Association class inquiry image:
Do I include the attributes as shown in the image?
Or do I assume that the Invoice would already have these attributes because it is derived from Appointment and Service and that it is not necessary to include them as they can be referred back to the keys apptNo and svcID?
I am confused about the concept. How should I present the association class?
Can someone please provide some guidance?
Thank you.
As already pointed out by Geert Bellekens in his comment above, you don't repeat any of the attributes of the classes involved in an association class in the association class. You only include attributes that specifically characterize the links classified by the association class.
In your example, you should only include attributes that are specific for Invoice links, such as invNo, invDate and totalPrice.
This rule holds independently of the kind of class diagram (domain/design/implementation model).
However, your model is only good for invoices refering to one appointment and one service. It does not account for invoices concerning one appointment, no matter how many services it includes. In a model for this business logic, Invoice would no longer be an association class, but an ordinary class associated with Appointment. This would allow it to access each service included in an appointment and turn it into an invoice line.
To make it short:
is (sort of; please read the comments below) an alternative notation for
which means that Class3 already has associations to both Class1 and Class2. So there's no point in adding attributes of the latter in the association class. If you're on a DB level you eventually introduce redundancy for performance reason at the cost of violating the principle of single source of truth. But that's another story.
It depends.
A domain model class diagram models the concepts found in the domain, i.e. the part of the real world relevant for your project. In the classes, you only include attributes that are indicated by domain experts or by other sources describing the domain.
I will assume that a domain expert knows what an appointment number and a service name are. If these were just technical data, they should not be attributes of Appointment and Service in the first place. To determine whether these attributes should also be included in Invoice, you need to ask domain experts what they think. Does an invoice always include an appointment number and a service name? Only if the domain expert says "Yes", I would model them as attributes of Invoice.
(To double check, you could ask "Is it also valid to say that the appointment number is not part of the invoice, but that the invoice is somehow associated with an appointment having a particular appointment number?")
Maybe the domain expert says an invoice does not contain the appointment number or the service name, because the corresponding Appointment and Service are always associated to the Invoice as attachments or hyperlinks or otherwise. In that case, the fact that Invoice is an association class on the association between Appointment and Service is enough. You don't have to include attributes of these classes in Invoice. These will probably be added later, when the domain model class diagram is turned into a system model class diagram or database model class diagram.
The diagram below is based on these facts:
A citizen may make a claim / reclamation on pollutions
An administrator will send the reclamation by type to the appropriate agency / organization, and it will respond with a diagnostic report
This report will be sent by the administrator, to another organization, for the estimation of the solution (costs, etc.).
My problem is to how can I show that Admin will send the claim to an agency? Do I have to make an association between Organization and Reclamation?
If your requirements include that the communication between the Admin and the Organization is to be documented, then you need to take care of this in your class diagram. And, in fact, you already have an item for this: the NotifyOrganization association class. Notice, however, that it's not a good idea to use the questionable UML concept of an association class, which does not have a clear semantics and is confusing. This seems to be confirmed by your flawed modeling of the multiplicities of the NotifyOrganization association, which must not be one-to-one (or 1 to 0..1), but rather many-to-many (* to *).
So, better replace the NotifyOrganization association class with an ordinary class (possibly with an improved name such as Notification) and attach it to Admin and Organization with two many-to-one associations such that each notification is linked to exactly one admin and one Organization.
Notice that a notification represents a (communication/message) event, so Notification represents an event type. It*s quite common in business information models to have both object types and event types, both as classes in a UML class diagram.
...how can I show that Admin will send the claim to an agency?
UML Class Diagram is not show-everything document. In order to document that admin will send claim to agency you can document it effectively using UML Sequence Diagram or some other behavior diagram
...do I have to make an association between Organization and Reclamation?
No, if the agency does not need to care about who exactly delivered the claim or what's the person's role (e.g. "admin"), then you don' have to add it to the class model (and show some association) at all
...diagram...based on these facts...
In order to describe the overall process in a one-page style picture, you (and your business partners) can find very useful the Business Process Model and Notation (BPMN) graphical language in addition to UML
If models in Master Data Services are representations of subject areas (such as customer, product, etc.), is it possible to have a domain-based attribute that uses a different model as it's source?
For example, if creating a customer model and defining an entity called Customers, this entity will have address information for the customer. City, State/Province, Country, etc.
But rather than creating an entity for CustomerCountry, can I use a Geography model that contains a Country entity and link to that? Then I can also use the Geography.Country entity for Vendors and Employees.
No, you cannot cross model boundaries - the primary reason is that a model is the unit of versioning. There are two workarounds:
Duplicate the entities in question - i.e. copy the geography entities into your customer model
Reference an entity by code - i.e. add a CITY_CODE to your customer entity
Neither of these are great options 1) is unwieldy and 2) doesn't maintain automatic integrity.
Personally I use option 2) where I can with some additional logic/business rules outside of MDS to ensure that codes match. This is easier with codes that are global and do not change such as country and city codes.
This seems quite old but this is now possible in 2016 and is accomplished though Entity Synch. The idea is you can synch your entity across models. There are two ways to run the synch, either on demand or automatically.
See https://learn.microsoft.com/en-us/sql/master-data-services/entity-sync-relationship-master-data-services for more details
I am using the Entity Framework and have an inheritance structure with a base Entity (let's call it Customer) and a derived Entity, let's call it AccountCustomer. The difference is that an AccountCustomer has extra details (such as payment terms etc.) stored in a separate table in the database and therefore extra properties in the Entity.
I want to allow users to 'promote' a specific Customer to be an AccountCustomer. I need to keep the same primary key (a composite key visible to users and used as the customer reference).
At the moment my feeling is that calling a stored procedure to create the additional record in the Accounts table is the only way to go, but up to now we have not bypassed the Entity Framework so would prefer to avoid this technique if possible.
Has anybody any Entity Framework focussed solutions?
This is one of those "Please don't do this" scenarios.
You are thinking about this strictly in terms of tables, instead of in object-oriented terms.
A particular customer is a particular customer. The kind of thing he is never changes. Now, his Status may change, or he may acquire additional AccountProperties, but he never transitions from being one kind of thing (Customer) to another kind of thing (AccountCustomer). It simply doesn't make sense conceptually (a generic fruit doesn't morph into an apple, does it? no! it starts as an apple with one status, and ends up as an apple with a new status), and it certainly is impossible in .NET object-oriented programming ... which would make it impossible in an ORM like EF.
So please think about a sensible way to conceptualize this, which will lead to a sensible way to express this in object-oriented terms, which will lead to a sensible EF solution.
I have solved this by a work-around.
Load all the related navigation properties of the base class, including itself
var customer = db.Customers.Include("whatever dependince you have").FirstOrDefault(u=>u.UserId == userId);
//you can repeat this for all of your includes
Cache the navigation properties to local variables i.e. var profile = customer.Profile;
Delete the base class by db.Customer.Remove(customer);
Create the derrived class var accountCustomer = new AccountCustomer();
Set all of its properties and navigation properties from the base class i.e.
accountCustomer.UserId = customer.UserId;
accountCustomer.Profile = profile; // do the same for all of the properties and navigation properties from the base class
Add the new class back to the db
this.Entry<T>(accountCustomer).State = EntityState.Added;
Call db.SaveChanges()
That's it!
I am trying to draw a domain model or class diagram in UML for car dealership. I am stuck with how to present test drive in the model. One way is to have appointment class and then test-drive as sub class. A dealer also offers after-sale vehicle service so i could have appointment/booking class as super class and then vehicle service and test-drive as two sub classes.
Another way is to have the customer class have a direct relationship with test drive class and vehicle service class under appointment class.
A dealer also sells new and used cars and their parts.
A dealer also offers finance for car sale.
Would testdrive class have relationship with vehicle class or there is separate class for display and testdrive class?
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
You can really only distinguish the right decision by having a good set of use cases or expected behaviors of the model.
This will inform whether a particular sub-classing is really accurate.
I can see that an appointment might contain several test-drives, which are themselves linked to individual vehicles, So a test-drive itself is nothing more than a link from a customer to a vehicle which are linked to an appointment.
test-drive would contain the information relevant only to the test-drive:
reference to the customer - even this might be debatable to include
reference to the vehicle
length of test drive
location (perhaps the vehicle was driven at a different location than could be determined from the owning appointment)
customer temperature (hot or cold - i.e. did the customer seem enthusiastic)
comments
etc.
But what is not in the test-drive object is anything related to the appointment - since it is always contained in a collection - possibly as part of an appointment or some other event container. Now if the containers which can contain test-drives always include customer information, I might not even include the customer reference in the test-drive object - after all, it will be redundant.
It depends if test-drives can occur in non-appointment scenarios - perhaps at a "sales event" or an "open house" or something where appointments are not actually created in the use cases - or if test-drives for multiple customers will occur within a container.
The second part of your question has been forgotten (easily done when you ask two questions in one):
Another question is how do I show potential customers and their inquiries about sale and service in the model. A dealer wants to save details of potential customers if they allow for marketing purposes. Shall I have two classes: one for customers and one for potential customers or it can be achieved just by using an attribute in customer class?
I think your use case there is "A dealer wants to save details of potential customers if they allow for marketing purposes." and the simplest solution is to have a Mailing List collection which holds name and address of each potential customer.
I think you miss the point. The aim of the domain model is make famliiar you with the domain:
-- What kind of entities you have in yor domain?
-- If they are important for your system under desing,
what kind of properties they have, how they behave?
-- What kind of business rules they obey?
The rest is details. Think like a map maker. Record what there is.Create a simple map so you can not lost your way in that domain. Not try to invent.Abstract what exist in the domain: Not run behind the "fancy abstractions" you created yourself.
Domain model can be used as a source
for object oriented analysis/design.
But their aim is not to represent
software abstractions.