I have a large vb6/sql database app (hundreds of tables, classes, and forms) that I want to migrate to c#, with both web, phonegap, and winform clients. There is a lot of database and business logic that I want to centralize, and since I prefer ASP.Net MVC as my web UI platform, I'm considering the following:
MVC Web project to include:
MVC Web controllers and views for web UI
MVC controllers to serve JSON objects to phonegap apps and rich html pages
Service classes to provide BLL services to MVC controllers
DAL classes to provide persistence and POCO objects for use by service/BLL classes
Webservices that expose Service classes to Winform apps. They would accept and return POCO objects
The Winform app will rely heavily on the Webservices for all of it's data. Since I have hundreds of database tables, the webservices will be returning this data to clients as POCO objects (some nested, some Lists of POCO objects). I'm worried that 1) the WSDL will be huge, and that as the app grows and the number of classes exposed grows, it will become unruly (will VS choke?), 2) returning POCO objects through a webservice may not perform well. I am used to calling SQL server directly from my winform UI, so the prospect of going through a webservice seems like it could become a bottleneck since everything gets serialized and goes through IIS.
Btw, I know the service layer is logically separate from the MVC UI layer, but I've combined them to make deployment simpler. I'd also consider WCF if it solved any problem, but as far as I can tell, it adds unnecessary complexity.
Are these valid concerns? Do you have any other advice?
How are you building the services that the WinForms consume? Depending on how things are setup, you may want to reconsider WCF. You could put the BLL in a WCF service. Then your MVC application, WinForms and PhoneGap application can all use the WCF service which means there is a single location for all of your business logic. As long as you're not dealing with gigantic POCOs and you're making async calls, you shouldn't have any major performance problems with your WinForms apps using a service.
WCF could be very nice here due to being able to easily expose different endpoints based on the clients you'll have connecting. Your MVC and WinForms app could use a binary interface for example, while your PhoneGap application could leverage a REST endpoint.
If you are worried about your service becoming too big, you could also consider breaking it up into multiple services, each which operates on certain parts of the database, or some other logical separation which may already exist in your BLL.
I also wonder why a WinForms app is necessary at this point. Is there something you cannot do on a website? Have you looked into WPF or Silverlight? Both work quite naturally with services.
Related
I have an MVC application that uses MVC Controllers to return views. Now I want to expose an API to other applications to consume, as well as returning JSON data types for some SPA features in the same MVC. What are the differences between adding Web API Controllers to my MVC Project vs adding a whole new Web API Project?
returning JSON data types for some SPA features in the same MVC
For that case, I'll place Web API inside existing MVC. By doing so, you can share business logic, services and even models.
In my case, I have SPA silos using AngularJS, and both MVC and Web API live happily in the same web application, and share business logic and data access layers.
It is worth noting that you can share Authentication cookie if you keep MVC and Web API together. Otherwise, it is pain in the neck to authenticate in both places at the same time, because Web API is token based and MVC is cookie based by default.
FYI: In new ASP.Net MVC 5, there won't be separate MVC and Web API anymore.
The only difference between the two is reusability and good design practice. I highly recommend to use it in a separate project. Then, later on, you will be able to reuse it without much or any effort.
Another advantage to segregate is the impact on testing required for any changes made. If you keep the projects different then if later on you change anything, the domain for the re-testing efforts would also be just the second project.
I am launching my startup and i need to make a critical architecture choice.
I will provide a SAAS web application for my clients, they have different specific needs but the main purpose of the program is the same, automatically generating documents and pdf.
Technincally i choose ASP.NET MVC, WebAPI, EF Code First. Now I have a working proof of concept with only one project (1 db, 1 asp.net mvc client, 1 asp.net webapi, 1service layer + 1 repository)
I will have one database for every client (easier to maintain, scale ...)
One WebFront for each client with personalized html/css templates and of course specific data/menu
Only one WebApi service exposing all services for each client,
For example /api/client1/, /api/client2/ with almost the same api calls but not the same data returned.
For each client a service layer (Class library dll) that stores business logic, data acess, POCO/DTO.
Each Webfront shares reference to specific service DTO/POCO.
I need of course my solution to scale horizontally, not vertically.
So is it a good choice?
Do you have any recommendation/better solution ?
Can I put All this in the same visual project ?
I really would like to have the service layer(business) in only one project, and with good Object Oriented approach I can serve all my clients with common needs shared between all of them and specific one in derived objects.
Thanks for help
I am a bit confused on the difference between using Grails domain model/service to inlcude my biz logic or make my Grails controller/services to talk to my application server and make the web layer separate from the application logic layer?
When do I select which?
What are the pros and cons of each approach?
Any gotcha using the Grails domain stuff specially for scalability and what not?
If you already have a web service that handles your domain and business rules, you can turn off db support.
If you do that, your grails app is effectively a thin web layer on top of another service. In this case, if you are going to enforce business rules, you could still do it in service/domain layers. However, I would not do this, and certainly not any complex validation, because the service should be your single source of truth for the app, and you don't want to duplicate business rules in 2 apps.
I would still use controllers for handling web requests, and services for interacting with the other service. I would also have some sort of simple domain layer for passing data thru the sections of the web layer (i.e. services return anemic domain objects, controllers serialize them to the client however makes sense). The majority of the work would be in the service layer, which would serialize and deserialize the communication with the other service.
Based on your comment, Grails is a fine technology for building your server layer. Why would you think it isn't? Grails bills itself as a rapid development environment; it provides everything you need for all layers of a standard web-app. You don't lose anything; quite the contrary, you gain quite a bit, such a integration with persistence, spring, a robust testing framework, etc.
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.