1

I have seen several Web - API projects samples for the last few days in order to improve my project's architecture.

What I have so far:
Project.WebApi - Mainly consists of controllers, scripts, etc.
Project.DAL - Contains my models and repository class.
And few more sectors which are irrelevant.

My questions are:
1. I have seen few projects which have their models AND repository classes together in DAL library, while others separate them. Is it a matter of opinion which one is better?
2. My controllers receive JObjects, therefore I found myself converting JObjects to data objects in my controllers more than once, and it seems so wrong to me. I would like to create a custom JSON convert class for each of my models. For such a class (and other similar classes to come), would it be fine to create a library named Common, or core? Or maybe I misunderstood the concept?
A code example:

var taskId = (int)taskstatus["Id"];
var status = (string)taskstatus["Status"];
var userCreated = (int)taskstatus["UserCreated"];
if (taskId == 0 || status == null || userCreated == 0)
                return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
var newTask = new Task{
Id = taskId,
userCreated = userCreated
...
}

Leaving all the code above in the controller looks wrong to me, the controllers should be more simple and cleaner.
3. The repository is as follows:

public class Context : DbContext
{
public DbSet<Tasks> Tasks { get; set; }
public DbSet<Projects> Projects { get; set; }
...

as simple as that. Again, back to my controllers - I find myself do many complex queries in my controllers, which again, I feel is wrong. I don't think that the controller should take care of such queries. What would be the best practice to deal with complex queries? Maybe I should make a new class which inherit my context class, overrides some of its parent class and do the complex queries there?

Skatz1990
  • 212
  • 7
  • 19

2 Answers2

1

  1. I would put it in the same project, since those classes are very tied to the database (but that may also depend on your desing).

  2. I would place object conversion code out of your controllers. And I recommend to use a conversion library, such as Automapper, or look for a pattern that is designed to do that. E.g.: Design pattern for converting one model to another model

  3. I would put complex queries in the repository. Simple linq queries (like queries containing only one orderby) could stay in the controller.
Community
  • 1
  • 1
Joanvo
  • 5,677
  • 2
  • 25
  • 35
  • Thanks for your answer. For such a class (say automapper), where would be the best place for it, to be placed? A new library named Common maybe? – Skatz1990 Feb 17 '15 at 18:00
  • I'd place them in the WebApi project, since this mapping will be WebApi specific, and you may have another mapping that maps to another kind of classes (e.g. you may want to map from data classes to WebApp model). – Joanvo Feb 19 '15 at 16:53
1

  1. Personally I would put your models in separate project. It makes it easy to share these with other projects in the future without having your DAL tag along.

  2. Agree with Joanvo, AutoMapper is the way to go. Also, having a separate project which contains the AutoMapper profiles for mapping your JObjects to your model/poco objects would be a smart move. You want your controllers as dumb as possible. In web api projects I've worked on the controller was almost always just there to accept the request and then hand it off to business layer (in your case mapping layer).

  3. You should NOT put ANY queries in your controllers....that is what your DAL is for.

Jacob Rutherford
  • 584
  • 3
  • 11