locked
In which project and namespace should I put class which isn't entity class? RRS feed

  • Question

  • User-1357109602 posted

    In my solution I have 3 projects: DAL, BLL and Web.

    I would like to move POCO classes (entities in database) to some other project - maybe called 'Model'. But what if I need to create class based on POCO class which isn't entity, for example when i must use group by clause:

    public class UniqueNotes // this isn't entity class
    {
        public string Title { get; set; }
        public int Count { get; set; }
    }
    
    
    // -----------------------
    
    IQueryable<UniqueNotes> groups = from p in context.Notes
                                        group p by p.Title
                                        into g
                                        select new UniqueNotes
                                        {
                                        Title = g.Key,
                                        Count = g.Count()
                                        };

    Should I put this class UniqueNotes also in project Model? In what namespace - for example in Model.BusinessObjects or something else? What is the best solution?

    Saturday, June 28, 2014 3:21 PM

Answers

  • User281315223 posted

    If you are defining any kind of "business logic" such as grouping raw data into more meaningful collections or objects and are doing so within an actual class (such as a ViewModel as Mike suggested) then I would consider your ViewModel to be a "business object".

    Basically, you are going to want to seperate your data / entities as follows :

    • Data Access - Basically, your entities. This is going to be your actual layer that handles accessing your data and updating it. You won't be applying any business logic within this section as that will be handled within another layer. 
    • Business Logic - Basically, your custom classes for applying logic like ViewModels. This area will be specifically for accepting data (from the Data Access area) and applying any business logic or rules to it. You'll use this to populate in this case a ViewModel that will apply all of your business logic.
    • Presentation - Basically, your ASPX pages or MVC Views. This area will accept your ViewModel or some other class or collection of data and handle displaying it to the user.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 30, 2014 1:00 PM

All replies

  • User-821857111 posted

    That looks like a ViewModel to me. I would add another folder to the Model project called ViewModels, or if you really want only Entities in the model project, create another project for ViewModels.

    Monday, June 30, 2014 2:48 AM
  • User-1357109602 posted

    Is it Business Object?

    Monday, June 30, 2014 11:49 AM
  • User281315223 posted

    If you are defining any kind of "business logic" such as grouping raw data into more meaningful collections or objects and are doing so within an actual class (such as a ViewModel as Mike suggested) then I would consider your ViewModel to be a "business object".

    Basically, you are going to want to seperate your data / entities as follows :

    • Data Access - Basically, your entities. This is going to be your actual layer that handles accessing your data and updating it. You won't be applying any business logic within this section as that will be handled within another layer. 
    • Business Logic - Basically, your custom classes for applying logic like ViewModels. This area will be specifically for accepting data (from the Data Access area) and applying any business logic or rules to it. You'll use this to populate in this case a ViewModel that will apply all of your business logic.
    • Presentation - Basically, your ASPX pages or MVC Views. This area will accept your ViewModel or some other class or collection of data and handle displaying it to the user.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, June 30, 2014 1:00 PM