Last post Jul 14, 2014 08:39 AM by jammycakes
Jun 26, 2014 06:58 PM|VirtualLife|LINK
Currently I am looking at something like this(including all incase someone else comes along looking for the same thing):
Interfaces (only needed in DAL?)
Needs View Models
Needs domain models?
Needs View Models
Needs domain models
My debate is where should I put the Interfaces/mappings?
It seems I should put them both in the DAL, but that seems a bit cumbersome.
Breaking out the interfaces into a separate project seems a little overkill since the only place I would need an interface is in the DAL.
The mappings from view model to domain model/EF model is where my real debate comes in. To me the DAL should be completely separate, but if I put the mappings in a different project, then the DAL layer is dependant on another piece.
I realize much of this is debatable, but just looking for some points of view.
And if it matters, I will have a base app, with about 4 MVC areas.
Jul 01, 2014 05:17 AM|Kevin Shen - MSFT|LINK
You can add your interface and mapping in the model layer not in the DAL,
For DAL Layer focus more on how to insert or update or delete data .
Jul 01, 2014 01:12 PM|Siva Krishna Macha|LINK
Agreed, I believe it is better to put the interfaces in a different layer and make DAL to depend on this layer.
Though this is an additional layer, in-future this may also be used by another layers. Also as others suggested, DAL could focus more on CRUD operations.
If you are sure that the interfaces will not be used by any other layer in future, then, you can directly put them in DAL layer - probably by creating a separate folder or so.
Jul 01, 2014 06:47 PM|VirtualLife|LINK
Maybe I missing something but wouldn't that create a circular dependency issue?
The interface needs a reference to the DAL so that it can reference the Entity framework models being passed in and the DAL would need to inherit from the Interface so a it would need to reference the interface.
Unless you are saying CRUD should be in a separate project from EF, which I've just never seen broken down that far, but that's not to say that isn't the best way.
Jul 14, 2014 08:39 AM|jammycakes|LINK
Don't use a separate project in your solution for each layer. It just adds friction and complexity (slows down compilation, makes upgrading NuGet packages harder, adds unnecessary complexity around circular dependencies) without giving you any benefit whatsoever.
Follow the Common Closure Principle instead: classes that change together should be packaged together. If you want to organise your code by layers, that's what namespaces are for.
For a basic web application, your solution needs just three projects: