Question

I have an SQL Server database with tables.

On top of this, I have a class for each table that uses LINQ and has Add, Remove, Get, Update functions.

On top of that I want to have more project specific methods.

For example, one of my highest level function is to Assign a task to an employee.

My thought would be to have another set of classes which would have this functionality, for example, the initial Task class has:

    public static IEnumerable<Task> GetAll(Schedule schedule)
    {
        KezberPMDBDataContext db = new KezberPMDBDataContext();
        return from p in db.Tasks
               where p.ScheduleID == schedule.ScheduleID
               select p;
    }

So for example, to assign a task, I need to GetUnscheduledTasks. I could have:

    public static IEnumerable<Task> GetUnscheduled()
    {
       return Data.Tasks.GetAll(emptySchedule);
    }

I’m basically trying to have: low level exchange data with mid level, and top level exchange data with mid level.

How should I organize or refactor my code to keep it clean and modular?

Thanks

Answer 1

So you have something like…

SQL > ORM layer > Business Layer. Where BL has routine:

“Assign a task to employee”

If we come to end of your post “trying to have […] low level exchange data with mid level…and top level…”. I suggest you look at the MVC pattern. The Controller acts as a middle layer between the Model and the View.

“Another set of classes to have this functionality”. I assume you mean another set of classes to assist the Controller. I tend to call these classes “helper classes” until I have enough relationships to define a less abstract name. I tend to include said abstractions in addition to my general MVC/MVVM/etc pattern.