I'm actually recreating the default architecture of my projects. In this post I want you not just help me,but think,tell and improve presented ways. This can be very useful challenge. This default architecture can be freely shared with all. So here is description: Basically MVC is our point of view. We follow OOP and layer programming concepts. Also we will use SQL Server and EF DB First. So here is what ive done till now: Ive created 4 layers in my solution:
- Domain: JUST domain classes
- DAL: responsible for accessing data, containing UOW and repositories and data access related validations.
- BL: unique responsible of business logic and unique boss of DAL.
- UI: which is not so important! (as even it maybe a console app!)
Ive implemented BL with generic funcs like getAll
and getById
and crud funcs.these funcs would call DAL generic funcs which is also ready.
Now an important question is: is it right to implement DAL funcs as GENERIC?
Please consider this scenario :
From UI we post a model to action and in action we call a BL Func (BL.insert
(model)). The BL.Insert
func would call something like DAL.Add
(model) (notice BL will call DAL once and will tell it what it wants). now the DAL.Add
func would have to insert 3 records into 3 different tables (model is passed from UI layer).
I think this cant be achieved by DAL GENERIC funcs. So what is the correct and standard way of implementing Layers and relationships with noticing the Separation Of Concerns?
In my action i would have:
[HttpPost]
public ActionResult Insert()
{
Bl.EntityBase.Article.Insert(new Article());
return RedirectToAction("Index");
}
in BL I would have:
public void Insert(T obj)
{
Da.Repository<T>().Insert(obj);
}
And in my DAL I have:
public virtual void Insert(T entity)
{
DbEntityEntry dbEntityEntry = Db.Entry(entity);
if (dbEntityEntry.State != EntityState.Detached)
{
dbEntityEntry.State = EntityState.Added;
}
else
{
Set.Add(entity);
}
}
See Question&Answers more detail:os