I came across a design in which there are different projects for the methods and data.

Example 1

What I meant is normally, if we have a USER class then

class user

{

 int userid;

 string username;

 //methods

public void Adduser(int id, string Name)

{

}

 public void RemoveUSer(int id)

{

}



}

We have a user object, attributes and the methods to manipulate the attributes. This is a normal design.

Example 2

what I came across are,

two projects

project 1. BusinessObjects

Project 2. Types (types for business objects)

Project 1 :

Public Class AddUser(AddUserInput input)

{

	Public void Execute()

	{	       //logic to add the user

	}

}

Public class RemoveUser (RemoveUserInput input)

{

	Public void Execute()

	{	//logic to remove the user

	}

}



Public Class User: Basetypes

{

int id;

string name

//overridden methods

}

public class Basetype

{

   //methods to override

gethashcode();

isnull();

isempty()

equals(); //etc

}

Project 2:



Public class AdduserInput : IOType

{

	int id, 

	string Name

	//overridden methods 

}



public class RemoveUserInput : IOType

{

	int id;

//overridden methods

}

public class IOType

{

 //methods to override

gethashcode();

isnull();

isempty()

equals(); //etc

}

As you can see different projects for methods and for the Types

---------------

I stronlgy disagree with the Example 2

because

1. No proper encapsulation ( data and methods are separated and any one can act on the methods)

2. The objects will be scatterd in the user interface. ( user interface will know the inner details of the business logic)

3. Design patterns can not be followed

4. Inheritance can not be used as c# doesn't support multiple inheritance and here all the objects inherit from BASETYPES. So no relationships can be established.

5. unnecessary coding

6. Design was selected before proper analysis of the requirements.

-------------------------

I need experts opinion on this Please. I feel encapsulation and inheritance are broken here .

Friend.. I can suggest another design

class User { 
//user properties, methods on the user instance
}
class UserCollection : IList<User> {
//users properties, methods on the users instance like add/remove...
}

I strongly disagree with the second method also. Projects should define library boundaries not class boundaries.

If you had a class that erased your HDD, a class that opened up a webpage and a class that calculated how old you were. Then I think it's perfectly acceptable that they go in their own projects (and produce their own dll file)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.