2

UPDATE:

what i am looking is should i go create each classes seprately instead of adding getter/setter prop in the class, what i mean by that is:

so in order to create a Visit i should have the following prop in VISIT

VisitName, Purpose, StartDate, EndDate, HostId, HostName, RequesterId, RequeserName

or should i have this:

VisitName, Purpose, StartDate, EndDate, IPerson Host, IPerson Requester

END UPDATE

i need advice/feedback if i am going on the right direction below is the domain model (part of the project not entirly).

i have class called "Visit" in that Visit model i will have basic of visit like name,purpose,start,end date etc... and in that class i also have who will be hosting the visit and who request the visit.

what do you think of the below class?

enter image description here

 //aggreate class
public class Visit
{
    IVisitBasic _visitBasic;
    IPerson _host;
    IPerson _requester;

public IVisitBasic VisitBasic
{
    get { return _visitBasic; }
    set { _visitBasic = value; }
}

public IPerson Host
{
    get { return _host; }
    set { _host = value; }
}

public IPerson Requester
{
    get { return _requester; }
    set { _requester = value; }
}

public Visit(IVisitBasic visitBasic, IPerson host, IPerson requester)
{
    _visitBasic = visitBasic;
    _host = host;
    _requester = requester;
}

public Visit() { }

}

Nick Kahn
  • 19,652
  • 91
  • 275
  • 406

1 Answers1

0

It looks ok as a start, but I wouldn't make a hard and fast domain model until you have actually started coding and testing the initial domain model as you will probably find that things don't quite work as expected or there is something that you have missed, or the requirements change, etc.

Other points from a quick look.

  • What is the purpose of VisitBasic, should it be an abstract base class or the name made clearer?
  • You may want to make the host into it's own class, it may have information not relevant to the person class, so possibly a sub class of person. But as stated above it may be better to develop it iteratively. And possibly requester as well but probably less likely.

UPDATE RESPONSE: The standard design now for most things is to add a service layer, i.e. VisitService with a createVisit method, and the properties on the visit object should just link to the host and requester without having any business logic in them. (Hope that answers your question?)

eaglestorm
  • 1,192
  • 1
  • 13
  • 32
  • please have a look at my question, i have just updated that.... – Nick Kahn Dec 30 '11 at 03:28
  • so where would you put the business logic? in model? – Nick Kahn Dec 30 '11 at 04:29
  • You basically divided your application up into layers, i.e. data access layer, model layer, service layer, gui layer, etc with it's own objects. but really depends on the type of application you are building, there should be some standards i.e. microsoft has the patterns and practices library and there are plenty of design patterns around. – eaglestorm Dec 30 '11 at 05:34
  • But no the business logic should go in a separate object (a service or manager class, etc) while the domain model should just be the data, attributes, etc. – eaglestorm Dec 30 '11 at 05:37
  • since you have said: `the domain model should just be the data, attributes etc...` so, do you consider this is a best practice to map table columns with the prop {get;set} in class (in this case model) ? – Nick Kahn Dec 30 '11 at 05:44
  • In general yes a column in a database table should map to a property on an object (collections are a little more complex). If you are building an VS C# or VB app check out the tutorials and doc on the entity framework that should give you some idea. http://msdn.microsoft.com/en-us/library/bb386876.aspx – eaglestorm Dec 30 '11 at 05:49