I am working as the sole .Net developer at a company and I have been tasked with a very large and complex project, an internal intranet site for inventory and time tracking. I have built a project that contains 3 applications, WebUI, Data Access Layer, and Core.

The WebUI is my normal MVC stuff, the DAL contains the models used by Entity Framework for the MS SQL DB, and Core currently holds all the helper classes I have developed. This has worked fine and well for me so far but now I have ran into a problem that I can’t figure out a decent solution to and I think it stems from the base design of my system.

In my timesheet controller I have a private method called GetTimesheetData which takes a data and an employeeID as input parameters, does some logic for ACL and some queries against the DB to get then returns an instance of a ViewModel with all the data in it. This code now needs to be accessed by other classes outside of this controller. This has presented me with the problem of where to move this code or if it needs to be broken up and moved into multiple places (what places I don’t know).

I was thinking about carving it up and moving the queries into my helper classes which do things like getting basic data from the DB (employee IDs, employee info, etc) and also things like some basic business logic like finding the pay period a given date is in or where or not a person is a manger and can approve timesheets.

How can I improve the design of the application to avoid having to recode the entire GetTimesheetData method into multiple places causing a headache if anything has to change in it?

Edit: In continuing to read things I can find on Google I am starting to think that I might need to add a new application for "Business Logic" that would contain models and more complex queries then what my helpers have or maybe extend my Core application to encompass this as well.


If I'm understanding correctly, your web tier references core, and core references the DAL.

In your core layer, create a service class that exposes the GetTimesheetData method like

public class TimesheetService
    public List<TimesheetDataModel> GetTimesheetData()
        // call DAL to get data

Then in your controllers and elsewhere, use this service

public class TimesheetController : Controller
    private readonly TimesheetService _timesheetService = new TimesheetService();

    public ActionResult Get()
        var data = _timesheetService.GetTimesheetData();
        return Json(data, JsonRequestBehavior.AllowGet);   

  • You are correct in the reference structure. WebUI references both Core and DAL, and core references DAL. If I where to move everything from GetTimesheetData of to a class in Core Where would I hold the model that it returns? Right now it returns an instance of a ViewModel held in WebUI, Would I need to basically recreate that model either in Core or DAL and then map that model to the VM? – Matthew Verstraete May 26 '16 at 15:12
  • In many of my solutions I have a 3-tiered structure like you have with an additional class library project that just holds models. I call it... Model. In there are container classes that are used throughout the app. Enums, and other shared model classes, but not classes with any behavior. Then all of my projects reference that model project and model doesn't reference anyone. The DAL can return models that the core layer needs without having to expose your entity classes to the core layer. Indeed, I usually make my entity classes internal for that reason, so they can't leave the DAL – rictionaryFever May 26 '16 at 15:53
  • I would still have to map the Model to the ViewModel in the WebUI every time I have to return that VM though, is that fine to do? – Matthew Verstraete May 26 '16 at 17:42
  • That seems reasonable. It sounds like the model returned from the DAL/Core layer can be used by many areas, each of which might need its own viewmodel. Depending on how much manipulation you have to do, you could create static extension methods to do the mapping in the core layer. something like var viewModel = timeSheetData.ToViewModel1List(); So the question is whether you should make a separate core layer method for each view model you need to select into or whether the mapping should be done in the controller. Up to you for what feels cleaner. A little mapping isn't so bad. – rictionaryFever May 26 '16 at 18:18

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.