1

As an expansion from my previous question about using separate projects for seperate layers - Good practice on Visual Studio Solutions

I now wish to know if I am putting the right functionality in the correct layers.

Background

I'm building a WPF application from scratch, that contains business logic and business objects. The database itself sits on another server on the web with access to it, restricted to web API calls using OAuth authentication.

I think the following content should be in these layers. The idea being, you go from layer 1 to layer 4, you are only depending on the layers below you. To prevent circular dependencies.

1. Presentation

WPF View (what the user will see)

WPF ViewModel (how the program responds to user interaction)

No WPF Model, as it will just be the business object

2. Application/Services

Repository (class used by ViewModel to load/save business objects)

Utility classes to assist in saving objects, by selecting the correct API calls.

3. Business layer

Business objects/Entities/DTO (whichever name is preferred)

Factories (Used by the repositories in the creation of business objects)

Other misc business class (i.e. storage of currently logged in user)

4. Infrastructure/Data Access

OAuth client (makes authenticated calls against the web server, used by repository classes)

Improve this question
2
  • 1
    You are only depending on the layer below you.
    – JeffO
    Commented Oct 10, 2011 at 12:34
  • That is the idea, but correct me if I am wrong. The system is not complex unlike this example - layersample.codeplex.com . Its does resolve around a business object (repair), which is quite large, then some smaller ones to represent customers. So in comparison is fairly small, but not small in my mind to be a single assembly. I was trying to avoid using reflection if possible, in order to learn to design it well.
    – JonWillis
    Commented Oct 10, 2011 at 12:46

3 Answers 3

Reset to default
2

The four layers you mentioned match the names of the layering I've used when I recently architected two our our company solutions. I also strongly agree to @Konamiman reply, Data Access and Infrastructure shall be two separate layer. In our solutions Infrastucture is a cross-cutting layer which can be referenced by projects in any layer. In the infrastructure layer we keep the logging functionality, security and validation code.

I would also consider adding a layer below the Data Access Layer called Entities. Put all your business object there, add Interfaces of of the entities in the Data Access Layer and reference the Data Access Layer with the Entities project.

I'm used to using non-strict referencing as you described, an upper layer can reference any of the lower layers. In a strict referencing an upper layer should only reference the the closest lower layer.

Improve this answer
3
  • Just as a query, would you consider putting the business objects in the infrastructure layer rather than data access (aka common layer). I just mention this because its possible that anything may want to reference them, so it seems suitable to be put in this layer.
    – JonWillis
    Commented Nov 9, 2011 at 13:01
  • @JonWillis I would put the business objects (i.e. entities) in "both" the business layer and the data access layer. The implementation of the objects (i.e. classes) I'd put in the data access layer. In the business layer I'd put interfaces of the business objects. This means you need to reference the business layer from the data access layer but has the benefit that your factories can depend on interfaces not implementation of your business objects.
    – Filip
    Commented Nov 10, 2011 at 1:57
  • Wouldn't the factory need to depend on the data access (class) and business layer (interface). As it would create the object defined by the class (i.e. new DataObject), but return a reference to the interface (i.e. public IDataObject BuildDataObject(string data))
    – JonWillis
    Commented Nov 15, 2011 at 17:12
1

Just a couple of suggestions:

  • Infrastructure and Data Access should be two separate layers. Their concerns are different enough for that.
  • Maybe "storage of currently logged in user" is better suited for the infrastructure class, as this data probably relies on a system dependant authentication/authorization system.
  • Repository implementations should go in the Data Access layer, but repository contracts should go in the Business layer (since the business objects know what are the persistence requirements).
Improve this answer
4
  • 1
    Why would you put the interface for the repository in the business layer, but the implementation in DataAccess layer. This would create a dependency from data access on another layer, which could lead to circular dependencies.
    – JonWillis
    Commented Oct 10, 2011 at 9:04
  • Regarding infrastructure/data access that probably should just be data access. The project does not create/maintain a database, it only makes calls to access a web server. Sorry for any confusion
    – JonWillis
    Commented Oct 10, 2011 at 9:06
  • 1
    @JonWillis there has to be some kind of dependency between the business layer and the data access layer - providing the interface in the business layer means that any data access layer implementation has a well defined contract which it must implement - that contract being defined by the consumer.
    – MattDavey
    Commented Nov 9, 2011 at 9:36
  • @MattDavey JonWillis is perfectly correct. If you put the Repository interface in the business layer and its implementation in the data access layer, and you assume that the business layer is above the data access layer, then what you get is not a layered architecture at all. To actually be able to talk about layers, we need to obey the fundamental rule of layering: a lower layer cannot have a compile-time dependency on a higher layer. Therefore, either the Repository implementation goes in the business layer, or the Repository interface goes in the data access layer; no other way.
    – Rogério
    Commented Feb 21, 2017 at 16:49
0

Nlayer design .net 4.0

Repository interfaces should be in the business layer (or) domain layer so that you can have different persistence implementations against your domain model. Note that interface belongs to the client not the implementer.

Data Access Logic could be in infrastructure since it deals with technologies such as EF or NHibernate. Everything related to the technology such as UI framework, DB framework, logging framework implementations could be in the infrastructure layer and you could have Infrastructure.Crosscutting and Infrastructure.Data name spaces.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.