1

In a 1 tier application i.e Mvc, you get a folder called models and you build and store your classes in there, I'm aware when it comes to a three tier application from what I have read it seems correct to store the models inside the business layer (2nd tier), and from the UI (first tier) I would add a project reference to the 2nd tier which will allow me to use the models and make calls to methods.

From the second tiers perspective it would call the data layer (third tier) and perform crud operations against the database, but the data layer would require the models from the business layer so when I try to add a project reference from data layer to business layer i get the error

A Reference to "Business Layer" could not be added, adding this project as a reference would cause a circular dependency

Which I understand as a reference has already been made via business layer to data layer

How would I get around this? do I create additional models in the data layer and populate them with results from the database and pass that back to the business layer which then passes it back up to the UI? I'm slightly confused on this.

** Update **

From what I have read for the data layer to reference models inside the Business layer I would need to do model mapping, My model mapping will be quite large so I'm thinking of including a 4th tier which will be a shared library and that will consist of all the models that way the data layer and the business layer can access the models as and when is required.

Code Ratchet
  • 5,758
  • 18
  • 77
  • 141
  • I think it would be good if you first clear difference between layer and tier. http://stackoverflow.com/questions/120438/whats-the-difference-between-layers-and-tiers – dotnetstep Jan 08 '15 at 08:05
  • You could read aboud MVP (Model-View-Presenter) for example, thats a 3tier approach. – user743414 Jan 08 '15 at 08:23

2 Answers2

0

You're on the right track but I find it easier to think of the model layer as the data (third tier), the controller (business layer, second tier) manages the flow of the data between the ui (first tier) and the data layer.

If you modify your architecture this way, you should get rid of the circular references.

This also allows you to map your data layer objects to the appropriate less/more complex structures of the middle tier in a way which simplifies the interface shown to the UI and encapsulates the business logic there too.

Mike
  • 2,120
  • 1
  • 23
  • 40
  • Further to this... "From the second tiers perspective it would call the data layer (third tier) and perform crud operations against the database". Not strictly true. It is the responsibility of the data/third layer to perform the CRUD operations. You can happily create an object in the second layer and call Save, leaving the data layer to determine if that should result in a create or update, where you leave that boundary is a little grey and your call, but the data layer is ultimately responsible for the final save (or rejection) of data. – Mike Jan 08 '15 at 07:33
  • I think I'm going to create a 4 tier application and stick all the models in the shared library and reference as and when it's needed, thanks for the information you provided – Code Ratchet Jan 08 '15 at 08:03
0

A little off topic but ...

Depending on the size of your application, there may be no reason to introduce unnecessary complexities to try and follow pattern you may not necessarily understand. Doing so, will cause you extra headache.

That being said, if your project is of a large size and requires some good organizing, I would strongly suggest more research and maybe a few sample project in where you try out the architecture you came up with. No way you'll get it right the first time.

I would personally suggest looking into "onion architecture" instead of "n-tier", and of course you'll find many different views on it. You'll have to make your own decisions.

Here's a generic set-up I would start off with.

Core. It knows about no other project. This is where your classes with your "business" go. Such as Customer, Product, Order, etc.

Data. It knows about Core. It is responsible for taking in a Core object and storing it somewhere. That is all.

Service. It knows about Core AND Data. It's job is to expose methods such as "Create Customer", it will be responsible for creating a customer and storing it.

Web / Api / Mvc. This will know about Service. It's job is to expose your service to the user. (UI and such). (It may also know about Core / Data ... but that's a larger discussion.)

hatcyl
  • 2,190
  • 2
  • 21
  • 24
  • what you have shown is what I was going with, I'll be taking a look at onion, I'll be doing a lot research before starting, the size of the application will be very large – Code Ratchet Jan 08 '15 at 08:52
  • in the structure you have shown me above where would the business logic go? – Code Ratchet Jan 09 '15 at 06:02
  • 1
    It goes in "Core" inside your classes so a class "Order" with "Order Items" will have a method called "GetTotal" which will return the order total price. Keeping your logic in core, will allow it to be isolated from any database / ui stuff and thus allowing unit testing / code re-use. – hatcyl Jan 09 '15 at 07:04