I recently started learning about ASP.Net MVC and its various features MVC_3_MUSIC_STORE +
CODE .
It looks very structured and simple to understand.
I was reading about enterprise applications and how they are layered/tiered in different sections
(logical/physical)
I was wondering(for learning ) how to do separate(convert) the above MVC_3_MUSIC_STORE into n-tier or 3 tier application (since we already have a working example) in order to have a clean separation of concerns.
I don't have much prior experience in this.
What changes would be required?
What will be different DTO(s) or POCO(s) that would be needed?
The above example uses POCO entities around from controller to views.
Would it remain same, assuming EF Code first is used.
Also i was wondering what changes will be required if WCF Webservice is introduced as a data access layer. i.e.Instead of retrieving data from DAL ,Clients will request data to and from WCF Webservice. Client can be Web app or WinForms or Sliverlight app.
( [DAL <--> WCF WS] <--> N CLIENTS)
Would be interesting to know about various approaches.
Example code would be helpful and/or examples for same.
Edit 1 - Added
One of the things I noticed was when i move the model classes from Model folder to new project "MYMODEL" I will have to again add reference to "System.ComponentModel.DataAnnotations" and "System.Web.Mvc" in new model project?
How can this be avoided? How can these validations be moved to Business layer?
Edit 2
Looking for something similar to this
Advice For A Newbie About N-Tier Applications
Normally the only change that will be required is that you will provide an implementation of the repository (DAL layer) which will call a WCF web service to fetch the domain models from instead of some EF DataContext talking directly to the database. A change completely transparent to Controllers and Views.
Related
I'm developing a web application that is going to use WCF as a buisness logic provider.
My solution consists of these 4 projects:
- ASP.NET MVC project
- UnitTests project
- ProjectCore - C# library with code first entity framework database
- WCF Service Application
My question is related to the WCF service and database model location.
Which option should I use (and why):
- Move code first EF db to WCF service application project?
- Add WCF service to ProjectCore?
- Leave it as it is in different projects?
I have maintained one big project where all WCF services were included in one Core library and it worked well but I wonder what you may suggest.
Practically it would work everywhere, but the right approach is a DAL(Data Access Layer) project.
So add another project containing your DAL objects and methods. This might seem a little unnecessary for an EntityFramework connected db, but for other type of more complex connectors(where you need to right your own queries) DAL is a life saver layer. Hence it's a good practice to get used to it.
so far in my office i have developed a number of small and medium sized .Net web based applications where i used to architect them something like this -
Web layer (.Net Web APIs)
Controllers, filters
Services (contains business logic)
IServices
Repository (gets data from database using entity framework / ADO.Net)
IRepository
ViewModel
Model
I used to have different projects for each of those listed above in my solution.
But now we are moving towards OData Web APIs and trying to get away with entity framework. So i am a bit confused about how my solution architecture should look like.
Question 1 - Where should my DBContext file be located?
Question 2 - How am i going to query using OData from Controller -> Service -> Repository
Question 3 - Can i still follow the architectural model given above and have OData instead of entity framework getting data from database?
Question 4 - I will still need a separate business logic layer (Service layer) between data source and controllers so i can keep my controllers as thin as possible
Please excuse if i am asking any wrong/silly question since this is my first effort trying to figure out how i can use OData to perform my tasks.
Following are the details of what we do in our project, if that can help you to an extent. We have Web API services, which have API controllers, which are used for Json serialize the end result. Following are the important layers and their respective roles:
Web API Controller
Receives the Rest request, Serialize / De-Serialize from / To C# objects
BL (Business Layer)
Business processing and External Service Integration (like Web services)
Helper Layer
In memory processing to convert simple Data entities / Poco's to complex UI / Return entities, which are finally converted to Json. This layer has lot of Linq to objects code to do the task well. It has fair amount of logic.
Repository Layer
Fetching the simple data entities, mostly as IEnumerable<T>, using our custom Micro ORM. Sometimes for specific cases we even fetch DataTable / Dataset directly and use them for further processing
ADO Helper (Custom Micro-ORM)
Use Reflection to fill a POCO at runtime, using DataReader or DataAdapter, this part can be replaced with any other dtaa fetch mechanism
Common Entities: (They can be accessed across layers defined above, though we restrict to ensure consistency)
Data - Simple POCO classes, which fills db data
UI - Final result entity
Input - For input from REST call
Constants - For hard coding and constant values across the project
All the C# layers below Web API can be created as dll, since the relation is unidirectional, from BL - Helper - Repository - ADO Helper. Any additional layer for a specific purpose can always be inserted or adjusted. It is important to separate the specific role of each entity.
Since I am new to MVC I have a few questions about the database connection.
I am trying to build an MVC application, and so far I have built 2 layers: Model(where my classes are, without any functionality) and Business (there is the functionality for my classes, every class has its own Business class) and there is also my MVC application. Both these layers are separated from the MVC project, I use them as ".dll-s". I am also using the repository pattern and the dependency injection is done by Unity.
Now comes the tricky part (or at least it is for me). I want to bind my application to a database. Most of the tutorials I have found rely on Entity Framework, but I don't want to use it, I want to use ADO.NET (Entity Framework makes me feel like I am giving my "power" away, so I want to manage the SQL on my own). So what is the best way to do it? How can I access the Web.Config from outside and read the connection string (or should I take care of the connection string inside the data access layer)? Is there any best practice how to manage the connection from "outside"? I mean I could easily just create a dbaccess object inside my MVC application, but I don't want that. In the MVC application I just want to use my business(object) classes.
And one more thing. What is the best practice for DataAccess: to build a new layer, or is it also fine to include the functionality inside my business layer? I am more tending to build a third layer, so I can reuse this code for any other application but maybe there are some other approaches.
You can create another project called "DAL" to handle your data access layer which is built using pure ADO.NET. You will add a reference to the entity project so that you can return these entities from your Data access methods. Now from your Business Layer, Add reference to the Data Access projects so that you can access these data access methods from the Business layer classes. From your MVC project, Add reference to your Business project ( and entities project if you are using those entity objects in your MVC project). In this way your MVC project do not have any idea what data access technology you are using.
You do not need to have connection string in your DAL project, Keep that in your UI MVC project and your DAL project will be able to read it as long as you have the proper references added between these projects.
I'm going to develop a web-based system with MVC4 which will use web services (WCF, exactly) for getting data from data provider (I can't use direct connection to SQL)
So, I have a question about using the web services in this project. Is this correct to use directly web service models as MVC model or I should create separate models for my MVC project and then map web service models to the models in MVC with an object-mapper (such as EmitMapper)?
Note: Consider that the web services may changes a lot.
No, don't use your WCF serializable proxy classes as MVC Viewmodels - this will couple the SOA back end to your MVC front end unnecessarily.
The 2 classes have entirely different concerns - e.g. you may want to decorate your ViewModels with DataAnnotations like UIHint etc which aren't applicable to your WCF classes (and similarly, your WCF Proxy classes may have serialization attributes).
Also, as your screens evolve, you will typically find that you may need to diverge the 2 models significantly - e.g. your screens need properties which your Service doesn't need, and vice versa.
So yes, separate classes for WCF data serialization and for MVC ViewModels, and as you've suggested, if you keep to a standard naming convention, mappers like AutoMapper will do most of the work for you.
I can only tell you what I would do.
Keep the models separate. As you say, the web services may change a lot. Having a halfway house may shield you from a lot of the implementation churn.
Also worth pointing out that:-
Easier to move to a different solution ( use a different strategy to populate the model )
Easier to unit test ( don't necessarily need a net connection to test that your model works )
I'm in the process of doing the analysis of a potentially big web site, and I have a number of questions.
The web site is going to be written in ASP.NET MVC 3 with razor view engine. In most examples I find that controllers directly use the underlying database (using domain/repository pattern), so there's no WCF service in between. My first question is: is this architecture suitable for a big site with a lot of traffic? It's always possible to load balance the site, but is this a good approach? Or should I make the site use WCF services that interact with the data?
Question 2: I would like to adopt CQS principles, which means that I want to separate the querying from the commanding part. So this means that the querying part will have a different model (optimized for the views) than the commanding part (optimized to business intend and only containing properties that are needed for completing the command) - but both act on the same database. Do you think this is a good idea?
Thanks for the advice!
For scalability, it helps to separate back-end code from front-end code. So if you put UI code in the MVC project and as much processing code as possible in one or more separate WCF and business logic projects, not only will your code be clearer but you will also be able to scale the layers/tiers independently of each other.
CQRS is great for high-traffic websites. I think CQRS, properly combined with a good base library for DDD, is good even for low-traffic sites because it makes business logic easier to implement. The separation of data into a read-optimized model and a write-optimized model makes sense from an architectural point of view also because it makes changes easier to do (maybe some more work, but it's definitely easier to make changes without breaking something).
However, if both act on the same database, I would make sure that the read model consists entirely of Views so that you can modify entities as needed without breaking the Read code. This has the advantage that you'll need to write less code, but your write model will still consist of a full-fledged entity model rather than just an event store.
EDIT to answer your extra questions:
What I like to do is use a WCF Data Service for the Read model. This technology (specific to .NET 4.0) builds an OData (= REST + Atom with LINQ support) web service on top of a data model, such as an Entity Framework EDMX.
So, I build a Read model in SQL Server (Views), then build an Entity Framework model from that, then build a WCF Data Service on top of that, in read-only mode. That sounds a lot more complicated than it is, it only takes a few minutes. You don't need to create yet another model, just expose the EDMX as read-only. See also http://msdn.microsoft.com/en-us/library/cc668794.aspx.
The Command service is then just a one-way regular WCF service, the Read service is the WCF Data Service, and your MVC application consumes them both.