So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))
Related
I've one missing link to understood how it could work to "connect" my EF core's DbContext to different applications in following scenario:
I've got one application project which contains the whole EF Core Code first datamodel (Entities, Business Logic, Enums etc).
Until now we're using a WebAPI application to share data with multiple endpoints.
So the data we're exchanging now are quite static at the moment. We create our DbContext and the API is using it for data reading and write operations.
Now there is customer request to also build a WebUI (Blazor). So we still want to use the WebAPI for data exchange in the UI, but further we need some more business logic elements from our data model (containing INotifyPropertyChanged event handling etc). We implemented the event handles in the entity classes. So we intend to build a session object for each user/client which contains the DbContext instance. But how can handover an instantiated DbContext from the Web API to my UI Application.
Would be nice to get some input. Thx for any advice.
You do not pass the DBContext object to "UI Application", such as a Blazor app.
You did not mention what flavor of Blazor you are using... However, the following may be applicable for both Blazor Server App and Blazor WebAssembly App... From what I've gather from your question you are exposing Web Api end points to retrieve data and save data. This is good. What is left for you to do is to create code in your Blazor that access those end points. You should use the HttpClient service to do this. If you use Blazor client side, this object is configured and made available for injection in your components and services. This type of HttpClient is based on the JavaScript Fetch Api.
If you are going to create a Balzor Server App, then you'll have to add the HttpClient service to the DI container and configure it accordingly, and only then you'd be able to inject it into your components and services. In this case you should use the IHttpClientFactory to provide the HttpClien onjects.
In principle, you have to query your Web Api methods via HttpClient.
Note that if you use Blazor Server App, you don't have to use Web Api. Instead you can create services that perform similar functionality to that provided by the Web Api.
Please, go to the docs and acquaint yourself how to use the HttpClient with Blazor apps.
Hope this helps...
We are writing a mostly single-page, client-side app, but server-side/DB endpoints are still required of course, so the natural choice is SpringMVC (since we are a Java / Spring shop).
But this got me thinking why we need the cluttered, very old design for this app:
- Controller layer
- Service layer
- DAO layer
This app is mostly just the client side making AJAX calls with JSON for DB retrieval/persistence. Do I really need to go thru the Controller layer to receive requests, then invoke a Service method, which in turn invokes a DAO method?
At the same time, I don't want to write a REST Service because it could result in overhead and we may not support all of the REST requirements... but is it the right choice here? If I understand correctly, I would still need a RESTController on the presentation layer?
My goal is to just directly hit a Service method or, maybe even more directly, a DAO method. Is that how modern apps are written?
You cannot hit a DAO unless you expose it through an API of some sort that can be invoked remotely by the UI application; as a consequence, you need to write a service.
A convenient way of exposing a service is to either:
Use Spring MVC and use the controllers as stateless endpoints that provide a JSON/Protobuffer/XML sort of payload that is then parsed by your API (with JSON being the simplest option of them all, perhaps) or
Use Spring Boot, which uses Spring MVC under the hood.
Hope this helps and good luck with your project.
After read the Gordon's article about Best Practices to build Enterprise Application using Spring Framework, I would like to share some ideas about the Service layer.
My architecture represents exactly what Gordon described in this image http://gordondickens.com/wordpress/wp-content/uploads/2012/07/Spring-App-Layers.png
The application is complex, has a heavy business rule and demands to use different resources like Database, SOAP, REST and file handle sometimes in the same use case.
For this scenery that I have described above, I have a Service class that needs to perform SOAP and REST requests and handle some database data. So, I have autowired in my Service class a SOAP and a REST component and the Repository to handle the database stuff.
I'm concerned about if this is the best approach do handle the integration between my Services and the resources like SOAP, REST, Database and etc.
Thanks
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds problematic even though it will work.
Think about the dependency between layers. Service layer will depend on Repository layer (Business logic layer will depend on data layer). Service integration layer (or service communication layer) for incoming requests will depend on the Service layer. But the data layer does not depend on the service layer. Nor the service layer depend on the inbound service invocation layer.
So, remove the SOAP and REST components from the Service class. To the SOAP and REST components, wire the Service instance (i.e. avoid SOAP and REST components wired into the Service, do it in the reverse direction).
This way, when you want to support another integration protocol (say JMS), you do all such work not by modifying your service.
Your data access seems to be fine. I hope your Service accesses the repository via DAOs.
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds fine. You are using dependency injection, this means they can be easily tested or altered.
I have been catching up with MVC4 Web API and WCF Data Service. From the surface, they both seem to be able to work with oData in the consuming client. I wonder which one is better for separation of concern (separate data service layer from UI layers). In my current solution, I have a plain MVC 3 style Intranet project and a MVC Data Service project. The 1st project has a Service Reference to the 2nd project. My goal is to write the data service once and make it available to all projects that would need to access underline database. When I read about Web API, it seems to me that the ApiControllers can return oData compliant result to the consuming client without MVC Data Service. My confusion is how I am going to expose this Web API MVC project as a service endpoint. Should I wrap it in WCF? Thanks.
You just create a controller inheriting ApiController and decorate one action with [Queryable] attribute, Rest depends on your route setup. Easy-Peasy.
Which one better? Web API. Since it has all the goodness of HTTP and you are not restricted to ATOM format.
You may use PocoHttp for seamless access of the data from your client.
We are planning to develop a big application in web, our current plan is to create a WCF service for each class in the Business layer. Is this effective? I want to know where can we use WCF in a big web application and main advantages of using it
we have these projects
1) MVC3 with Razor that handles UI
2) Class Library Project that communicate with Database
3) WCF Project
Method we using
1)Creates UI and Model in MVC
2)Makes dll that communicate with UI (eg:Save function/Update function) using ClassLibrary Project
3)The Class Library Created is Added (Added to Bin) in WCF Project
4) Builds the WCF and Host It in Server
5) The Hosted Service is Used in MVC Project for Communication with DB
Our Technical lead is saying it is light weight and more secure but i am wondering why he is saying to use WCF for whole appication
First ask this question, why do you need a service layer, when it could be achieved by a separate application. If you want to achieve this for just loose coupling, then it does not makes sense.
In my opinion, the service layer would be useful for exposing your data (dal-layer) and not Business Layer. For example take twitter. Twitter exposes it data over Web Services. What you do with the data is completely your interpretation. The data could be consumed by many application over HTTP. So your client could be remotely situated and need not to be on the same server as your application. The business layer could change based upon interpretation of data. The consumer, then need to worry about latest changes and including latest DLL. It will just consume the webservice. Also mocking your service would be pretty easy and you could write your NUnits tests very easy on your Business layer then. I would also recommend you to have a look at ASP.Net Web API, which provides restful way of exposing your services and data(with inbuilt capablity of exposing it as JSON). The RestFull service has many advantages over WCF, like you then need not to worry about WSDL and etc. The interface always remains same. Consuming a RestFul service is very easy.
As again with the twitter example. The clients consuming twitter api's are not situated on same server. So it makes sense to expose it over HTTP.
But if you do not have such a requirement(Client is not remotely situated), then exposing your data over web services does not make sense. Then a separate application will give you loose coupling and that should be good enough for you. Also exposing data on HTTP will have some performance impact too.
UPDATE 2
I understand the scenario you are trying to implement and I think its perfectly allright. By light weight he means, from your WCF service he would do interaction with Database and then send light weight DTO's for each action and controller as per requirement. So basically your WCF would do nothing but invoke methods from your class library, would fetch some Business Object and Convert it back to DTO(as required by your action to render UI) and send it to Controller.
Also make sure, you use Dependency Injection for your Services, so that you could write NUnit tests for your controller with mock data and hence no requirement of Database for running your NUnits
My preference is to have the service layer be a completely independent application that can be consumed by many applications. It makes projects, especially large ones, much easier to scale, than if you were to create your service layer inside a single web application.
Unfortunatly to tell you. Using WCF is less effective. The main purpose to use WCF it to let your data can be accessed with any client application. not just web application. you may also have a Silverlight or winform. WCF has nothing to do with "A BIG" web app.