Robertcode
Robertcode

Reputation: 1001

Where do business logic methods go in a layered application using entity framework 6 with Visual Studio 2015

I am using Visual Studio 2015 with Entity Framework 6 and .NET 4.5.2. I am building a WinForms application. I have structured my application in a layered fashion as follows:

Solution name is TrackingSystem.

Projects under the solution are:

The TrackingSystem.DomainClasses project contains several class definitions which were generated from the Entity Framework Power Tools add-on. These are plain and simple POCO style files. Just the class name and properties for each domain entity. Example:

Public class Location
{
  int locationId {get;set;}
  string businessName {get;set;}
  string cityLoc {get;set;}
  string stateLoc {get;set}
  string zipCodeLoc {get;set;}
}

I reference the TrackingSystem.DomainClasses project in my TrackingSystem.UI project and include it in the uses statement of my WinForms code area. I have it setup this way so I don’t expose all of the classes and methods in my domain layer.

The question I have now is the placement of requests for the various entities. For example, Let’s say I want to add a request as follows:

public List<Location> getAllLocations();  

I don’t want to add this to the Location class in the TrackingSystem.DomainClasses project because those classes are to be simple POCOs.

Since this is something the domain would provide after asking the DAL I do want it to be in a class under the TrackingSystem.Domain project. This is where I am not sure how to proceed. I could create a class under the TrackingSystem.Domain project called Location but then I would have a duplicate class name in the solution. So maybe I could name it LocationServices where I can add requests related to the Location entity. If I do this I’m not sure if this should be at the root of the TrackingSystem.Domain project or perhaps under a folder called DomainEntityServices. Wherever I put it that would be the place I would create similar classes for requests related to other classes (i.e. ProductServices).

I would appreciate some ideas here as to how others may be setting this up or if there is a guidelines document some place that addresses how to setup a Visual Studio project for layered solutions. Thanks in advance.

UPDATED DESCRIPTION 11/21/2015 7:11 AM I found an example project which shows one case where the POCO and implementation code were placed in the project. In this case, the POCOs and BLL were in separate projects but they retained the same entity name. In this case a Customer.cs file existed in the POCOs project and BLL project where the BLL project contained the implementation while the POCO project just POCO content. The sample project is at the below URL:

https://code.msdn.microsoft.com/Multilayered-Architecture-703a0d69

UPDATED DESCRIPTION 11/20/2015 1:36 PM In particular, I am looking for what to do when the requested service can be answered in the domain without asking the DAL such as the following business rule: The City must be San Bernardino. In this case, where in the domain do I put this rule check which does not require checking with the DAL? Do I create a new class like LocationServices which would have the logic to check this rule and if so where would the class be placed in a Visual Studio project considering where my projects already are?

Upvotes: 0

Views: 780

Answers (1)

Paul D&#39;Ambra
Paul D&#39;Ambra

Reputation: 7814

In this situation I'd have an interface in the domain

public interface IAmALocationsRepository 
{
   List<Location> getAllLocations(); 
}

In your domain you use this interface.

In your DAL you implement it

public class LocationsRepository : IAmALocationsRepository 
{
   public List<Location> getAllLocations()
   {
     //do things here
   }
}

This way your domain says it is possible for there to be a list of locations that I can use but I don't care where it comes from.

And your DAL provides the list without the domain being aware.

Upvotes: 1

Related Questions