locked
Advice on Architecture RRS feed

  • Question

  • User1780985398 posted


    I came across a design in which there are different projects for the methods and data.
    What I mean 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.
    what I came across is,
    two projects
    project 1. BusinessObjects
    Project 2. Types 
    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
    }
    ---------------
    I stronlgy disagree with the second method
    reasons are
    1. No proper encapsulation
    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.
    5. unnecessary coding
    6. Design was selected before proper analysis of the requirements were made
    -------------------------
    I need experts opinion on this Please.

    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 is,

    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 .



    Tuesday, May 18, 2010 6:49 AM

Answers

  • User-2004844803 posted

    Hey john john,

    Its always hard to judge when you dont see the big picture, this just a pice a code taken from a bigger context I asume? Anyway, I do agree with you. But there is one thing thats good, the overriden methods, you might wanna use that in your code in example 1.

    hmm, and I dont get why there are "AddUser" and "RemoveUser" methods in the actual user class. For me they rather belong to the user repository.


    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 18, 2010 9:28 AM