-
Sep 7th, 2019, 03:12 PM
#1
Thread Starter
Hyperactive Member
ASP.Net trying to understand 3-tier with auto-mapping and dependency injection
Hi,
I am from a hobbyist background using Windows Forms and am learning ASP.Net MVC. I am currently trying my hand at understanding the n-tier architecure, specifically trying to implement a 3-tier solution with the following projects that so far contain the listed items (they have been pieced together from my interpretation of various tutorials that each provided pieces of the puzzle, but not the whole puzzle):
++++++++++++++++++++++++++++++
+++ [Project.Application] ++++
++++++++++++++++++++++++++++++
[References]
=> Project.Data
=> AutoMapper
[Config Folder]
=> AutoMapperConfig.cs (Profiles for Project.Application.DTOs and Project.Data.Models)
[DTOs Folder]
=> DTO Models
[Services Folder]
=> Service Classes
+=> [Interfaces Folder]
+=> Service Interfaces
++++++++++++++++++++++++++++++
+++++++ [Project.Data] +++++++
++++++++++++++++++++++++++++++
[Config Folder]
=> App.Config (Storing database connection)
[Models Folder]
=> Model Classes
[Repositories Folder]
=> BaseRepository Class (Implements the IConnectionProvider)
=> Repository Classes (Inherits from BaseRepository)
+=> [Interfaces Folder]
+=> Repository Interfaces
[Root Folder]
=> IConnectionProvider Interface
=> ConnectionProvider Class (Sets up the database connection using the App.Config connection string)
++++++++++++++++++++++++++++++
++++++++ [Project.UI] ++++++++
++++++++++++++++++++++++++++++
[References]
=> AutoMapper
=> AutoFac
=> AutoFac.Integration.MVC
=> Project.Application
=> Project.Data
[App_Start Folder]
=> ContainerConfig.cs (Setup the AutoFac DependencyInjection container and registers MVC Controllers/Services/Repos and AutoFac profiles)
=> MapperConfig.cs (Configures the AutoFac mapping profiles found in Project.Application)
++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++
At this point I have some questions:
1. Am I going along the right path? My initial understanding is that my Appliation project should be acting as a go between for the UI and Data projects, however the addition of model mapping and dependency injection require me to add project references to the UI layer (for the sake of configuration) meaning I can no longer reference the projects in that way.
2. I am now at the point of setting up a Controller in the UI project and think I should create my ViewModels here as well. That pushes me towards configuring mappings between the UI ViewModels and the Application DTOs which are already themselves mapped to the models in the Data project. It just feels wrong to map data twice between the UI and Data projects.
3. Do you know of a good resource, or example project, bearing in mind I know this gets tricky with the addition of AutoMapper and AutoFac for model mapping and dependency injection (i've searched around alot already).
Whilst there are probably better implementations than a 3-tier solution with the configuration I am using, I am hoping to achieve this moreso for my own understanding before then exploring other avenues.
Thanks for any help
Jay
Last edited by JayJayson; Sep 7th, 2019 at 03:16 PM.
-
Sep 8th, 2019, 03:54 PM
#2
Re: ASP.Net trying to understand 3-tier with auto-mapping and dependency injection
If you UI project reference Project.Application and Project.Application only accepts and returns DTOs then you might not need the reference to Project.Data from Project.UI - normally I would avoid the front end referencing a data layer directly.
Converting between DTOs and ViewModels and back again can certainly seem like a lot of wasted effort, the thing to realise is what the benefits of each are.
Firstly having the Project.Application return DTOs rather than exactly the same data model as being used by the data layer has a couple of benefits.
Firstly it isolates Data Layer changes from the UI as much as possible, the DTOs contain data types and data structures that make sense in the UI / Application layers without also passing Data Layer specifics around. This could mean mapping DB types to more appropriate .Net types, preventing DB only fields such as PK/ FKs being passed around to layers that don't need or understand them.
Secondly the Application layer can implement more reusable business logic that is made available to the UI without it being implemented in the UI portion of the application.
DTOs are a form of abstraction between the UI and the Application layers.
A ViewModel is a way of allowing the UI's Controllers to shape the data into a form required for a view or to receive information from a GET / POST than can be mapped into a suitable form for the controller.
e.g. If a DTO received from the Application has data that is usable across many views it might be too generic for any one single view, a ViewModel could include pre-calculated values, summarised information or similar. A ViewModel that is used to receive input could include View specific validation or only have properties for the relevant fields - that way ModelBinding will only work with properties on the ViewModel and not an entire DTO.
ViewModels are effectively a way of shaping or restricting the data for use within a particular View or Views(s)
So although they seem to be duplication of effort they serve slightly different roles and have different emphasis on what they do.
-
Sep 9th, 2019, 02:43 PM
#3
Re: ASP.Net trying to understand 3-tier with auto-mapping and dependency injection
I'm going to get annoyingly pedantic for a moment... PD brought it up with out really intending to do so, or really knowingly doing so...
To be perfectly clear, odds are, what you have is likely to be 1-tier ... with 3-layers, or possibly n-layers. What's the difference? Physical layout. There's a reason it's called the Presentation Layer... the Data Access Layer, the Business Layer... that's what they are... the different layers of the application. What makes a tier is the physical separation of those layers. The web server, the application server, the database server, etc... So while it is possible to segregate your code into different layers, if you have them all physically on one box, that's a 1-tier, n-layer application... add in a separate database server, then you start adding tiers. Add in an application server where the business logic lies, separate from the database server, and separate from the web server, now you have a 3-tier architecture....
-tg
-
Sep 10th, 2019, 02:46 AM
#4
Thread Starter
Hyperactive Member
Re: ASP.Net trying to understand 3-tier with auto-mapping and dependency injection
Originally Posted by techgnome
I'm going to get annoyingly pedantic for a moment...
-tg
Haha thanks, it's all part of the learning curve and the explanation phrased that way will help it stick. Perhaps one of my biggest flaws is that terminology does not sink in as easily as coding does.
Thank you both for the feedback. I think I have now got the layers in my solution setup and running as I would like. Moving some of the Dependency Injection config into the my Application project allowed me to lose the reference to the Data layer from my UI to tick that box. And the model mapping between layers is working now with a basic API test to validate it all.
I imagine the point of creating these layers is so that you can configure them to be deployed on the different tiers as you rightly said much more easily.
Im ready to start looking at other architectures now so if you have any good suggestions please let me know.
Thanks
-
Sep 10th, 2019, 06:54 AM
#5
Re: ASP.Net trying to understand 3-tier with auto-mapping and dependency injection
Originally Posted by jay20aiii
Haha thanks, it's all part of the learning curve and the explanation phrased that way will help it stick. Perhaps one of my biggest flaws is that terminology does not sink in as easily as coding does.
I went five years before I learned the difference between tiers and layers... FIVE years!!!! O.O
And even then it was only happenstance that I found out. I mention it because I've seen some employers ask the question in interviews to see if people really know the difference.
Originally Posted by jay20aiii
I imagine the point of creating these layers is so that you can configure them to be deployed on the different tiers as you rightly said much more easily.
Partly... gettign things into the different layers is the first step but it isn't necessarily the only reason. Another reason is say databases support. Even if everything is all on the same box, let's say today you need to support SQL Server.... then next week some one comes to you and says the application now needs to run on Oracle... Well,since you broke out the data access into it's own layer, you only need to rewrite that part, swap out the old DAL for the new DAL, and BAM! just like that your app is now talking to the Oracle database instead of the SQL Server database. Or, a more likely scenario is that to make the application more marketable, you develop multiple DALs that allow your app to talk to different types of databases that allow your client to then choose which DBMS they want to use for the application. Maybe they have MySQL already installed and want to use that... or use some sort of online database.... by separating the different layer of logic from each other, you create layers of insulation that protect the other layers from change. the UI doesn't give two farts where the data comes from... all it knows is that it needs to display X, Y, and Z. So that's all it should know about: X, Y, and Z. How and where that came from is the business of another layer. Conversely, how X, Y, and Z get displayed isn't a concern of the DAL... all it knows and is concerned about is that it needs to get X, Y, and Z from some place.
It's about creating areas of concern and responsibilities and making sure that those boundaries are adhered to.
-tg
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|