Design and Architecture

Quake2Player16-Jun-09 12:16

16-Jun-09 12:16

You didn't quoted my entire message.

In fact, the question starts with an "if", so you are entering an "If" without checking the condition.

I understand that one wants to decouple (sorry bad english) the VIEW from the MODEL.. but if the VIEW already contains the MODEL (that is, a composition relationship), you already have the coupling there. As I see it, you've already losed the idea of encapsulation.. because another person working with you could type "m_model." and he would see all the public methods that allow him to modify the model directly from there (from the view). So, again, once you've decided to add the model to the view (Model m_model), I don't really get how the controller helps, in fact it makes the view to take a long road for something it could do (GIVING THAT IT CONTAINS THE MODEL) in less steps.

And btw, a pattern is not a good pattern "just because".

led mike17-Jun-09 4:50

led mike

17-Jun-09 4:50

Ok. Good luck.

Leslie Sanford18-Jun-09 7:50

Leslie Sanford

18-Jun-09 7:50

Quake2Player wrote:
I have a very simple question:
If the View is supposed to know the Model (that is, the View has a field of type Model),
why would I need the controller if the view can modify and get responses from the model directly?

You don't necessarily. Many frameworks combine the controller and view into one, e.g. MFC's Document/View architecture.

Quake2Player18-Jun-09 8:17

18-Jun-09 8:17

Thanks,
Another question:
What would be better: That the view works only with strings/numbers or that it works with objects from the model, for example

Creating an account:
a vs b:

(a) User press a button for creating an account after filling the form -> The form sends all the data(strings primarily) with an event (CreatingAccountRequest) -> the controller listens this event -> the controller creates an account object -> adds it to the model

(b) User press a button for creating an account after filling the form -> The form creates an account object -> The form sends an account object with an event (CreatingAccountRequest) -> the controller listens this event -> the controller adds it to the model

Viewing an account:
a vs b:

(a) The form uses the Tag property of controls to contain the objects from the model (for example an Account in a ListViewItem' tag)

(b) The form uses the Tag property of contrls to contain an identifier of the object of the model (for example an Account id)

Leslie Sanford18-Jun-09 8:21

Leslie Sanford

18-Jun-09 8:21

Quake2Player wrote:
(a) User press a button for creating an account after filling the form -> The form sends all the data(strings primarily) with an event (CreatingAccountRequest) -> the controller listens this event -> the controller creates an account object -> adds it to the model

(b) User press a button for creating an account after filling the form -> The form creates an account object -> The form sends an account object with an event (CreatingAccountRequest) -> the controller listens this event -> the controller adds it to the model

I definitely like (a) better than (b) because it decouples the view from the model; the view in the case of (a) is completely ignorant of the model. If the model changes, it's less likely that the view will be affected.

Quake2Player18-Jun-09 8:30

18-Jun-09 8:30

Thank you,

Any opinion about the second thing, SHOWING/DISPLAYING ?

Leslie Sanford18-Jun-09 8:59

Leslie Sanford

18-Jun-09 8:59

Quake2Player wrote:
Any opinion about the second thing, SHOWING/DISPLAYING ?

(a) The form uses the Tag property of controls to contain the objects from the model (for example an Account in a ListViewItem' tag)

(b) The form uses the Tag property of contrls to contain an identifier of the object of the model (for example an Account id)

I'd prefer (b) for the same reason. That way the objects stay inside the model where they belong; the view has no direct knowledge of them. If they change structure at some point, it's less likely to affect the view.

This is just my opinion...

The boundaries of each subsystem, in this case the model, view, and controller, should appear as flat as possible to each other. That is to say each subsystem has a nice, flat API that the other subsystems can access. So instead of something like this, for example:

SomeObject obj = model.GetSomeObject(int id);

obj.SetValue(123);

You have this:

model.SetValue(id, value);

In the second example we have no knowledge how the model represents the values inside. All we want to do is set the values or whatever.

CodingYoshi7-Jul-09 17:28

7-Jul-09 17:28

For a few reasons:

1. Separation of Concerns (SOC): The model should be what the name states--just a model. It should not have other logic. Any logic which is outside the domain model of the "model" and is used for controlling should go in the controller.
2. A pattern is to build vocabulary amongst developers. You do not have to implement it this way. And if you don't, then you are no longer using MVC so you can not tell other developers, "I used MVC pattern here but I decided to throw out the controller."
3. There are many occasions wherein designers have decided to put the controller logic within the model, for example, many .NET classes do databinding this way. DataTable sends an event when data is changed, and the DataGridView handles the event.

Your question below about option a and b, I would go with option b and pass the object over. But instead of asking the object for its state using properties, I would do the following:

Lets say I have Employee class

public class Employee
{
public string Name
{get;}
public string LastName
{get;}
public string FullName
{get;}
public int Age
{get;}
// I will have one method as below which will return the state in a structure in one shot
public EmployeeProperties GetState()
{
EmployeeProperties props = new EmployeeProperties();
props.Name = this.Name;
props.LastName = this.LastName;
props.Age = this.Age;

return props;
}
}

public struct EmployeeProperties
{
// The fields for the struct
}

There is no right and wrong way. It is like art, you might have a more elegant solution than anyone has ever had.

CodingYoshi

Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07

Quake2Player7-Jul-09 17:37

Client Server Protocol Definition - Best Practices

7-Jul-09 17:37

Nice! Didnt thought on that solution..
Instead of having large methods with a lot of parameters... Thank you

Member 404718314-Jun-09 17:16

Member 4047183

14-Jun-09 17:16

Hi All,

I am planning to develop a client server application . Can anyone let me know the best way of defining the message protocol between client - server.

Re: Client Server Protocol Definition - Best Practices

Jimmanuel15-Jun-09 0:40

Jimmanuel

15-Jun-09 0:40

There is no best way, it depends entirely on what you need to communicate between the client and server.

Badger | [badger,badger,badger,badger...]

Re: Client Server Protocol Definition - Best Practices

led mike15-Jun-09 4:28

led mike

15-Jun-09 4:28

Member 4047183 wrote:
Can anyone let me know the best way of defining the message protocol between client - server.

Requirements

I have a couple of design issues

Mycroft Holmes13-Jun-09 15:54

13-Jun-09 15:54

In the past I have used datatables as my data "entity". So if I wanted a list of rooms for a house I have a stored proc for GetRoomsForHouse(HouseID) and this would reside in the Rooms class.

Now with List<> I am moving to lists of objects as my data "entity". My current structure (LoadObject) is up the FK path ie Fitting inherits from Room from House from Street etc. So getting a fitting (stool) will get 4 records from the database to load the ingeritance tree, this is fine and works well if there you are working with 1 stool.

Now I want all the fittings in Room101, this potentially generates 4 x #n fittings calls to the database to load the List<fittings>. This is still reasonable but when I want a list of all fittings in 60 storey tower block it gets a little overwhelming.

In the past I would simply have a proc to get all fittings by a number of different criteria and use the datatable to load the display controls. So I have a number of option to follow:

1. Continue with the proc to datatable - this precludes using a List<> to populate data list controls
2. Use the LoadObject method and wear the database calls - worst case and will not be implemented Dead | X|

3. Use a proc to get the data IE Fittings RoomName,HouseNo,StreeName etc and create a class to service a List<fittingsforxxxx> with the results from the proc.
4. Split my design of an object to display/process where display gets only the data used to load into list controls. The process object would be a full inheritance tree of a single object (Fitting).

I want to use 3 but it means there will be a plethora of classes in the app to support display. 4 may be the better option as it standatdises on the object rather than the proc.

The amount of code is not an issue as I will use my code generator to build it all.

2nd issue
When dealing with lists of objects should the list reside in the parent or the child eg:
Room has a List<fittings> and while the select for the List is on Fittings the List is on Room - Parent has the list.
Fittings has a List<fittings> for a Room and retains the List on the Fittings object - Child has the list.

Never underestimate the power of human stupidity
RAH

CodingYoshi11-Jul-09 9:24

11-Jul-09 9:24

I don't understand your question. Is your question basically that you know how to load one object from the database but loading multiple objects seamlessly from the database (or any storage) you are having trouble with?

CodingYoshi

Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07

Mycroft Holmes11-Jul-09 14:56

11-Jul-09 14:56

I thought I had wasted my time with this question.

No I have no problem managing the data it is the design I am tossing around. When dealing with a list of something do I create the list in the something class or in the parent class.

2 classes, Department and staff. I now want a list of staff for the department. Is the best design I am after.

Departmant
List of staff for department(this.DepatmentID)

Staff
Get for Department(DepartmentID)

Or both, hah thats probably the right way. Staff gets the list for a department because it is a list of staff and department calls the same method on staff to get the list of staff for itself.

The problem is I use stored procs ALL the time so there would be a proc out there called StaffGetForDept(@DeptID) and deciding on the owner class for the proc is sometime an issue.

Never underestimate the power of human stupidity
RAH

CodingYoshi13-Jul-09 3:35

13-Jul-09 3:35

I don't like the idea of asking the Staff object to return a list of Staff objects. A staff should have methods and properties for a Staff but not a list of Staff. I would take one of the collection classes (if using .NET or something similar if using else) and extend it like below:

public class StaffCollection : List<Staff>
{

private Department _department;
// Inject the object with the department at construction
// Now this staff collection realizes its department
public StaffCollection(Department dept)
{
this._department = dept;
}

public void Load()
{
// Load this from the database. I will create a DAL and pass a reference of this to it so it can load it for me.
}

// You can put many other methods--based on your requirements--here. For example, find all employees who earn more than 100K and it will return a bunch of employees who wear pink shirts and have spiked up hair
}

Here is the department class

public class department
{
// put everything for department here: email, name etc.

private StaffCollection _staffs;

public Department()
{
this._staff = new StaffCollection(this);
}
public void LoadStaff()
{
// You can check first if already loaded or just reload everytime
this._staff.Load();
}
}

You will still need a Staff class and might need a DepartmentCollection class.

CodingYoshi

Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07

Mycroft Holmes13-Jul-09 14:37

13-Jul-09 14:37

CodingYoshi wrote:
I would take one of the collection classes

Now that makes sense, I have no collection classes in my design, all the lists (I usually use datatables) come from the single class, this is b/c of my reliance on datatables (and recordsets of course) in the past.

Never underestimate the power of human stupidity
RAH

God object problem

Quake2Player9-Jun-09 13:50

9-Jun-09 13:50

Hi,

I think I've got a god object antipattern problem, or not, please tell me:

I have a class Admin that contains several lists of things that might interact each other,
for example: It contains a list of Messages, Accounts, Contacts, Filters etc.

The problem is that some of them interact with each other.. for example, the AddMessage method applies all the filters in the filters list.

The Admin class is pretty big.. because it haves Adds methods, Deletes methods, ..so it has like 2*(fields that are objects or lists of objects) methods

Do i have a god class or is it well justified?

In case I do have a god class, should I split the Admin class in several Administrators? like AccountsAdmin, ContactsAdmin, FiltersAdmin, ..? or what?

Thanks

Mycroft Holmes9-Jun-09 14:50

9-Jun-09 14:50

I would have an Admin PROJECT and a class for each of your entities (accounts, contacts etc)

Never underestimate the power of human stupidity
RAH

Quake2Player9-Jun-09 14:58

9-Jun-09 14:58

You didn't get the problem.

I DO have a class Account, Message, Filter, etc.

Mycroft Holmes9-Jun-09 15:53

9-Jun-09 15:53

Quake2Player wrote:
In case I do have a god class, should I split the Admin class in several Administrators? like AccountsAdmin, ContactsAdmin, FiltersAdmin, ..? or what?

I assumed the admin for the classes is done in the one Admin class. I try to keep any lists etc in thier respective classes eg the Contacts list is always found in the Contacts class and admin uses the ContactClass.List, it never has a copy of its own list of contacts. If Filters need a contact or list of contacts it goes to the contact class, admin does the same.

The only time I vary this is if Filters needs a special list of contacts and Thingy needs a different list of contacts for some reason. Then I allow the other classes to have their own lists internally.

Never underestimate the power of human stupidity
RAH

CodingYoshi13-Jul-09 3:40