Search code examples
c#asp.netn-tier-architecture

N-tier Object Parameters

I am struggling on n-tier concept. At first I had this concept that my domain entity would be shared across my 3 layer been ( DAL, BLL, Service). But was recently told this was an old concept and didn't really follow SOLID concept. and instead was told to create and object for each layer.

Service
  ObjectService
Business
  ObjectBus
DAL
  Object

Which yes Service still depends on business, business depends on dal and so on. However I am not to sure how to pass my object or how to create them.

Lets say at my data layer I have a person.cs with the following properties

public class Person:Base
{
    public string firstName { get; set; }
    public string lastName { get; set; }
    public string middleName { get; set; }
}

In my business object should I create a business method like this

Boolean CreatePerson(userrole r,string f, string l, string m);

Or should I do something like this

Boolean CreatePerson(PersonHandler pmo);

Where I have a class PersonHandler

public class PersonHandler
{
    public UserRole r { get; set; };
    public Person p { get; set; };
}

In this case userrole is just extra properties that the business layer would need. I like creating an object for the business layer, as I could change all the properties associated to this object easier, however I feel I still need access to the domain entities ( Person ), which I was told this was bad. But If I create a set of properties for each object I just feel this would be redundant . what if in the future I change my person at DAL, wouldnt that mean I have to change every parameter going up the ladder?

Here a sample more in def of my structure folder

enter image description here

This is my structure for DAL.

enter image description here

Solution

  • You structure seems like complete overkill. You state you are using entity Framework. This is an ORM is is supposed to map you business entities/objects to data structures and should be used as such.

    Why not create you domain using EF code first with attributes to map the domain entities back to the sql table? I'm assuming there's sql at the back end. keep your business logic in your domain model or you risk the chance of creating an anemic model

    For the front end, I would define viewmodels that represent the screen/view you are presenting to the user since this is separate from the domain objects. Then populate the view models from your domain objects.