Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)

share|improve this question
1  
You are only depending on the layer below you. –  JeffO Oct 10 '11 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 Oct 10 '11 at 12:46
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 Nov 9 '11 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 Nov 10 '11 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 Nov 15 '11 at 17:12
add comment

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).
share|improve this answer
    
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 Oct 10 '11 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 Oct 10 '11 at 9:06
    
@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 Nov 9 '11 at 9:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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