https://stackoverflow.com/questions/19864729
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFor starters, it's good to consider 3-layer design but just know that in practice it will seem like there are more layers than 3. Fundamentally though, there are 3 layers.
Presentation Layer
Any application you build will have some sort of presentation layer. It may be actually presentation, or it may just be the layer that returns data that a client expects (e.g. a web service response, a client UI in HTML/JavaScript, etc.) Normally you would have some classes that represent your client-side data, often referred to as a ViewModel or just a Presentation Model. The key here is that the data is specific to the view you are presenting. An example would be an order history form that just shows the Order Number, Order Date, and Total Cost. You may not need to know the Username, Cost per Line Item, how many shipments, tax amount, shipping methods, etc. in this particular view. There's a lot of debate on how ViewModels should work and whether they're necessary. It just depends on your app. The key is that if you go with this approach, ViewModels are just light-weight classes that hold data that your view/page uses.
Business Logic / Domain Layer
This is the layer that generally can be broken out into several pieces. They may include the following:
- Domain Objects or Business Objects - These are the object representations of your business logic. In Domain Driven Design (DDD) and pretty much any other programming paradigm, this is where your business objects should reside. They may be classes the represent customers, orders, accounts, etc. The key here is that they are a representation of your data that makes sense in the context of your application. They may not resemble the data in your database, and they may not resemble the data that you display to users, but in your application, they are structured to make sense.
- Repositories - These are "collections" (I say that in quotes because they may not actually be collections) that hide the complexity of your data layer and return copies of your Domain objects. The idea here is that if you need an Order object, you ask the repository for it. For example, OrderRepository.FindByDateRange(startDate, endDate). Again, the key here is that your business layer should not have to access data directly; repositories mask that complexity and also allow you to change the source of the data easier, be it a database, xml, cache, etc.
- Helpers or Business/Domain Logic - These are generally classes that sit in your Business Logic layer that do things specific to your business. They may include validation, calcluations, data manipulation, etc. The key here is that they work with the business layer data and perform actions on it within the context of your business needs. For example, you may have a business need to ensure that all orders have at least 3 line items for free shipping. That's a business rule, and it should be enforced within your business layer.
Data Layer
The data layer is the actual code that communicates with your data store. It may be ADO.NET or an object-relational mapper like Entity Framework, nHibernate, or other. This is where any SQL or other data queries would reside (T-SQL should be in the database as much as possible of course, but it's forgivable here depending on the type of application, IMO.) The key here is that your business and presentation layers should know NOTHING about where the data actually comes from, only that they receive it in an expected format. This data layer is what returns that information. Usually a data layer will query a datastore and put the data into a class of some sort (sometimes called a Data Entity or a Data Transfer Object). These are used by repositories to generate the above mentioned Business Objects.
Additional Resources
In the above layers, you may also have some mapping classes which help create Business Objects from the Data Objects, for example. Projects like AutoMapper help with this, though admittedly I don't have any experience with it.
It's a good idea to learn about polymorphism and interfaces. Abstractions become increasingly important for this layer separation. An abstraction would let a repository get data from either a database or a completely different source, but the business layer shouldn't care which. All the business layer needs is to get some data back in an expected format and it shouldn't care from where. I would seriously consider looking into the following: SOLID design principles, Design Patterns (at least Repository, Adapter, Factory), Dependency Inversion Principle (not necessarily Inversion of Control frameworks or anything yet, at least until you understand the principle of dependency inversion)
Just Remember:
This is a simplified example, probably filled with misinformation and arguably bad design, but hopefully helps to separate the layers a bit in your head. There are a lot of different opinions about architecture and when it boils down to it, the best answer I can give you is it really just depends. Usually separating out into the parts I mentioned above will help you get started. It sounds like you're a bit of a green developer but don't get discouraged. You can spend hours every day for years and never fully be happy with how you build your software. Just focus on something that works and refactor when it makes sense. I've been trying to learn the best way to do it, and I've been reading articles for months and still haven't found it.
Good luck to you.
