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.
Related
I need suggestion on how best we can implement APIs for large scale enterprise application has a couple of child web applications running inside root application. For example Root, Child1 and Child2
There are separate MVP projects for each application is hosted in IIS. MVC apps have only front-end logic, business & data access layer is hosted in another WCF projects(a separate WCF project for every child). Front-end MVC app only routes requests to target WCF application.
Now I'm planning to design APIs for each application. I'm not able to decide whether I should create a separate application which will hold APIs for all the child and root application or should add API in each application. Like front-end MVC projects, APIs will also redirect to centralized WCF application.
There is a common logic applicable to all the APIs(rate limiting, authentication etc...), if API is in each application then I would have to replication logic in all the three apps.
There are trade-offs either way.
The advantages of developing separate APIs include;
Isolation
Easier to change
Independently deployable I.e. Can scale independently
Might be easier if different development teams are involved in the different APIs
The disadvantages include:
Need to decide if you want to repeat common code in each API or extract a common shared module (this then reduces the isolation advantage)
More infrastructure / ops to deal with
If you want coordination in terms of rate limiting across all APIs this is harder than if they are a single API
My default position would be to develop separate APIs, but your particular use case (routing requests to other things) might be solved by some existing tool such a nginx - I'm not knowledgable about these so cannot advise
I have read through the SimpleInjector documentation a few times. But have a few questions.
Context:
3 tier app (presentation (mvc + api controllers), service (business logic), data (repositories, entities, etc)
Unit of Work is a thin wrapper around EF's DbContext
my DbContext and Unit of Work are registered PerWebRequest, using
RegisterWebApiRequest causes an exception, because the Unit of Work is used
outside of Web API requests.
my MVC and Api controllers registered using RegisterWebApiControllers(GlobalConfiguration.Configuration) and RegisterMvcControllers(Assembly.GetExecutingAssembly())
Each controller has one or more services injected into it.
Each service has one or more repositories injected into it.
A service may also have another service injected into it.
I want the same Unit Of Work/DbContext to exist in all my services/repositories.
Questions:
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
Please read the following q/a: How to configure simple injector container and lifestylse in a MVC web app with WebAPI, WCF, SignalR and Background Tasks. The answer explains that:
Putting your Web API in the same project as your MVC controllers is a bad idea from an architectural perspective.
But if you want to do this, you can use the WebRequestLifestyle in both type of applications. The WebApiRequestLifestyle is meant as lifestyle that works for Web API for both IIS and self-hosted environments, but since you placed the Web API controllers in the same project, you are clearly only interested in IIS-hosted; in that case the WebRequestLifestyle will do just fine.
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
Both lifestyles use a different way of caching. The WebRequestLifestyle uses the HttpContext.Current.Items dictionary to store its SimpleInjector.Scope instance, while the WebApiRequestLifestyle uses the CallContext class to store the Scope during the lifetime of a single asynchronous operation.
Just as the WebRequestLifestyle can be used while resolving Web API controllers, you can use the WebApiRequestLifestyle (or the underlying ExecutionContextScopeLifestyle) for MVC controllers as well. But if you want this, you will create your own IDependencyResolver implementation for MVC that will explicitly start and end an ExecutionContextScope. The absense of a Scope stored in the CallContext is the reason resolving MVC controllers fails when registering services using the WebApiRequestLifestyle. But while it's possible to use the WebApiRequestLifestyle in MVC, the otherway around is much easier, since no custom code is required.
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
If services don't have state, it doesn't matter what lifestyle they have. The only restriction is that they have dependencies that have a lifestyle that is equal to or longer than their own. Violating this restriction is called Captive Dependencies and can cause all kinds of trouble. Because captive dependencies are bad, Simple Injector v3 checks and prevents this for you.
Although you can probably make all objects in your configuration scoped (non-transient), making them transient is usually easier to configure, and might result in better performance (although you will probably never notice the difference in real life).
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 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.
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.