1
\$\begingroup\$

This is how I imagine my project's layering:

BLL

Should be independent and contain only pure business logic and properties Sample Domain Model:

public class Role
{
    private UnitOfWork uow { get; set; }

    public Role()
    {
        uow = new UnitOfWork();
    }

    public int RoleId { get; set; }
    public string Name { get; set; }
    public string ID { get; set; }
    public string Description { get; set; }

    public int AddRole()
    {
        //Mapping from Business 'Role' type to Data Model 'Role' type
        AutoMapper.Mapper.CreateMap<SoC.BLL.Role, SoC.DAL.Role>();
        var model = AutoMapper.Mapper.Map<SoC.DAL.Role>(this);
        return uow.Roles.Add(model);
    }
}

DAL

Contain generic repository and Unit of work and data model meaning model that will reflect the database. Sample Data Model:

public class Role
{
    [Key]
    public int RoleId { get; set; }

    [Required]
    [StringLength(50, ErrorMessage = "Name Cannot Be More Than 50 Characters")]
    public string Name { get; set; }

    [Required]
    [StringLength(6, ErrorMessage = "ID Cannot Be More Than 6 Characters")]
    public string ID { get; set; }


    [Required]
    [StringLength(250, ErrorMessage = "Description Cannot Be More Than 250 Characters")]
    public string Description { get; set; }
}

Web

This will be ASP.NET MVC app that will use BLL. (Should or should not be aware of DAL?) Sample Controller Action:

public ActionResult Index()
{
    var role = new Role { RoleId = 1, ID = "ADMIN", Name = "Administrator", Description = "Hello World"  };
    int check = role.AddRole();

    return View();
}

So, from app I am communicating with the Domain Model which has a AddRole() method that will first map using automapper to the equivalent Data Model and then call Add() of repo method to persist the record.

This way my BLL is becoming a little dependent on AutoMapper and DAL but my DAL seems independent. I am trying to create just a simple layering for a simple yet well maintained project. Please suggest on its problems and improvements.

\$\endgroup\$
2
\$\begingroup\$

To start off, I have no idea what a SoC.DAL.Role is. Your namespaces are short abbreviations. This is quite hard to follow for people not really into your project.

Your role can add itself to a repository. This is not behaviour that I would expect. I would have a simple repository class (RoleManager?) that is capable of adding roles.

Role role = new Role(...);
new RoleManager().AddRole(role);

As such, you have 4 layers. One data access layer, one model layer, one domain layer and one GUI layer.

\$\endgroup\$
  • \$\begingroup\$ Thanks for your reply. SoC.DAL is namespace for Data access layer and Role is the type that totally reflects the DB and I call "Data Model". What is the difference between Model and Domain layer in your suggestion? \$\endgroup\$ – lbrahim May 20 '14 at 12:31
  • \$\begingroup\$ Also would not be violating many principles if I create Manager for each Model? \$\endgroup\$ – lbrahim May 20 '14 at 12:34
  • \$\begingroup\$ Your object Role is responsible for things related to a role. Persisting something to the database is the responsibility for a database connection class. You should not build a Manager per class, but create them on a higher level. An example is per subject (Role management, like Roles, rights and such) \$\endgroup\$ – user42171 May 20 '14 at 14:04
  • \$\begingroup\$ You have not mentioned the difference between Model and Domain in your answer and also are there any article or examples you can link me to your approach? \$\endgroup\$ – lbrahim May 21 '14 at 5:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.