I have business layer and UI layer in separate projects within a same solution. What i need is ,connect this UI with business layer which coded in c#. UI created using MVC3 Razor.
What i should use as model in MVC application? am i need to create Service reference to business layer to generate some proxy?
then can i use those proxy as a model? please help me..
if you can provide me some tutorials
i tried this but no more idea with MVC :
http://www.dotnetfunda.com/articles/article816-understanding-the-basics-of-wcf-service-.aspx
Unless your project (or architect) demands that all methods of your app access a services layer, I would try and avoid using WCF unnecessarily (think of it - it means that all of your data between web server and back end goes over the wire, which has implications such as performance, serialization of data, and also potentially limits the lifespan of database connections and transactions, which can deprive such as lazy loading).
If you concur, the suggestion would be to ensure all accessible interfaces in your business layer are exposed on an interface, and then consume or inject the BLL interface directly into your controller.
You need to be careful about the word "Model" in MVC - ASP NET MVC encourages ViewModels, which are specific to the presentation tier and passed between Views and Controllers, as opposed to "Entities" which represent the more logical domain model as used by business logic and which can be tied to data persistence using an ORM such as EF or NHibernate. The MVC project template lumps everything which isn't View or Controller into "Model" which isn't necessary very helpful.
However, if you do choose to access your BLL via a WCF Services layer you still have some design decisions to make:
Choose whether you share the back end entities on the client side, or do you instead use proxied entities.
Choose whether you consume / inject the WCF service proxies directly in your controller, or do you create another facade layer (e.g. CAB calls these ServiceAgents). The latter would make sense if there are separate teams or vendors building the SOA side vs the Client side in order to accomodate changes to interfaces.
Related
I have started working on an application which is structured as follows:
UI - ASP.Net MVC web application
Service Layer - WCF
Entities - a simple class library (exposed by WCF layer)
Data Layer - for database interactions.
Till now, I was defining my models in Models folder of my web application, but now as we have decided to expose them by WCF service (as this application will be consumed by other applications as well), I need some help here.
I tried putting all my model definitions in Entity layer which is exposed by WCF service decorating them with data annotations as well as DataContract attributes. Now, I am able to reference these entities to bind them with my views. But, data annotation validations are not working for me.
Can anybody please help me for a workaround for this ? I have been searching through web for solution but almost all tell me to put a reference of entity layer in web application which will be tight coupling that we do not want. and the other option is to redefine all entities with data annotations in models folder of my web application,which will be duplicate kind of coding.
Is there any better approach for this? Any help appreciated.
Update:
To consume WCF entities, I have put a service reference in my web application. Now, just to check I modified that Reference.cs file by decorating my data Member explicitly with [Required] attribute and it is working fine. but, I understand these changes will go away whenever service code is generated.
Is there any way I can bring that Data annotation attribute here? Kindly help.
As for me It's bad idea, DTO for transfer, Model for MVC.
Look like similar problem
Why You Shouldn’t Expose Your Entities Through Your Services
DTO’s Should Transfer Data, Not Entities
I’m aware that not everyone uses a thorough architecture when developing an MVC application but let’s assume I have the following architecture:
App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project
App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service
Inside our MVC application we try to follows this approach:
Inside our Controller (within a method), we instantiate a ViewModel.
We fill that ViewModel calling methods from our App.Service Layer
Once the ViewModel is filled, we return it to the View (so the view
is now strongly typed).
This occurs 99.9% of the time. It is clean, we like it and it leverages itself pretty well..etc!
Now my question is the following:
If we decide to move our application to MVC 4.0 and start using the
new Web API approach, I’m not sure I fully understand where (or how)
it would fit in our current architecture?
Keep in mind, that we are open to change this around!
Should we create a new App.WebAPI layer that sits between the App.Service and App.Web?
This means inside our Controllers, we would no longer need to call the App.Service directly but instead the new App.WebAPI layer?
Or, leave the Web API inside the App.Web layer and make the Controllers call the other APIControllers which in turn would call the App.Service layer?
Not sure if I make any sense here…but please feel free to suggest anything as I’m curious on different inputs.
Thanks
There are a couple of cases to consider:
Do you want to make this Web API serve as service layer and data access for your MVC application? If, yes, then you should completely remove all references of App.Service from the ASP.NET MVC project and have it query the Web API instead to fetch the data. In this case the Web API sits between your ASP.NET MVC application and the data access. It is the Web API that talks to the service layer and exposes it over the HTTP protocol.
Or do you want to provide an additional API for your web site that can be used by other clients (other than web browsers)? In this case the ASP.NET MVC application and the Web API sit on the same layer. Both query your Service layer to fill view models, it's just that in the case of the MVC application you are passing those view models to views which in turn convert them to HTML whereas in the Web API layer you probably use slightly different view models but which are still populated from your service layer and are passed to the client used the corresponding serialization mechanism (JSON, XML, ...)
I know this is late but I was actually looking for the same advice and I found this post.
Wouldn't having "both the MVC and Web API sit within the same layer" mean more maintenance work on the code, or maybe duplication of code? isn't the mvc web considered as a browser client? .. to me it makes sense to have the WebAPI your only layer to everyone else and in turn it would call your service layer for processing.
What is the benefit of leaving both the Web API and the MVC talking directly to the service layer? Can't the web API be the wrapper around the service layer?
I have an existing set of Services and Repositories I use in an MVC application that leverage the Entity Framework 4.1 Code First.
I want to create a couple of WCF Services that use the existing architecture, but it seems to have a hard time serializing the object graphs.
I realize that there are some circular references to deal with, but I really don't want to litter the Domain Objects with WCF attributes, so should I just create View Models like my MVC app uses? And if so, should I create the View Models to be able to be used in both?
Any other ideas? - Thanks!!
I prefer keeping my domain model and the WCF data contract separate by defining Data Transfer Object classes as the data contact of the WCF server. They are tailored specifically to carry the right data across the wire. A good DTO design will keep the number of WCF service call roundtrips from the client down. It will also separate your internal domain model from the contract with the client.
Hi
we have used the WCF service in my project. In our application the following layers are exists,
UI (aspx file), and code behind.
(Customer.aspx)
UI entity Model (CustomerModel.cs)
which is properties of the customer
details.
UI layer calls the Business Façade class with the CustomerModel object.
In Business façade I have referenced the WCF service.
Convert the CustomerModel to CustomerContract.
Call the CustomerService from business façade.
In the service, I have convert CustomerContract into CustomerBO and call the CustomerBO class.
In the CustomerBO class,I have initialized the provider object and call the customer Provider class.
In Provider class, I have access the Database and send data from 8 to 1 layer.
I don't know which design pattern is using in our project. Can anybody help on this to identify design pattern.
Thanks
This is not about design pattern but about architecture. Your architecture itself is not bad but it is really complex so unless you are creating very big project this architecture can be overkill. Moreover your naming of different layers is not correct. What you call BusinessFacade is usually called ServiceAgent. BusinessFacade should be placed on service site and wrapped by WCF service. Usual responsibility of BusinessFacade is to aggregate several business operations into single calls = create less granular API which can be easily and effectively exposed for remote calls.
I am new to WCF but have been working on asmx services for a while.
We have an effort underway where we want to introduce a service layer between our UI/aspx pages and Database Layer. Most of the business logic exists in codebehind. So the current setup is UI/aspx->DAL->Database. We want to do UI/aspx.vb->WCF->Business Layer->DAL->Database i.e by moving everything from codebehind in WCF...Is this a good approach?
Our future goal is to get the flexbility in replacing business layer, so there is no dependency between UI and business layer or database.
Need some guidance on how we can use WCF in right way to do layered architecture approach..
Your help is much appreciated.
Thanks.
In principle service layers are a good idea but if you're simply introducing one for the sake of it then it's a lot of effort for no return.
The main benefit you will get from a service layer is that you will have a lot more flexibility in the type of clients you can connect to it. At the moment it's likely that the only application that can use your DAL is your ASP.Net app by adding a service layer and exposing it using WCF end points you'll have the option of connecting other SOAP or REST clients which is a good thing for future enhancement.
However if you're only ever planning on using your DAL with your existing ASP.Net app then there's no guarantee that you will gain anything and in fact could make your life harder by adding a service layer. If you do all your data retrieval server-side, i.e. don't use AJAX, then a service layer would be pretty pointless.