37

Great question! I'm always looking for a better way to structure my projects.. Each point you raise has merit and having explored a variety of solution structures I have to say that I agree the majority of the comments here: there is no perfect solution. A few things to ask yourself when faced with this kind of problem: How complex is this application? ...


17

Is CQRS a relatively complicated and costly pattern ? Yes. Is it over-engineering ? Absolutely not. In the original article where Martin Fowler talks about CQRS you can see a lot of warnings about not using CQRS where it's not applicable: Like any pattern, CQRS is useful in some places, but not in others. CQRS is a significant mental leap for all ...


10

I'm also somewhat skeptical that every new web app needs to be an SPA but one thing I'm 100% sold on as a generalist with the bulk of his experience on the client side is that a service-oriented architecture that hands off raw data rather than HTML to the client is the way to go whether you're loading prebuilt pages/views from the server and doing a lot of ...


9

The RouteConfig.cs file isn't required for Web API. It is included by default in new Web API projects because that template also includes an MVC webpage (for the index page that appears when you open the project in a browser). If you delete both the RouteConfig.cs and the HomeController.cs file (as well as modify Global.asax.cs to not call RouteConfig....


9

I have experience with Ninject, not Castle Windsor, but the principles should be the same. To understand dependency injection, it helps to recall how you wrote code without it. Typically, the DepartmentsController constructor would look like something like this: public DepartmentsController() { _repository = new DepartmentRepository(); } The ...


8

It's never absolutely necessary for a controller to be async. Calls to controller methods will eventually return. However, it might be desirable to hand off a long-running task to a thread, so that the web server is not blocked for a long period of time. I wouldn't bother making every controller asynchronous. There is some overhead involved in creating ...


6

Directly accessing your business objects directly (I assume you mean in your controller) will be quicker & easier. what if client wants to host API and web on different cloud server and apply scaling only on API or may be he want to have different url for accessing API and Web (which is somewhat logical) Then you'll need to host them separately......


6

I know you cannot have multiple gets according to REST Not really. REST and API modelling are different subjects. REST APIs are meant to be an integration strategy, based on the premises introduced by Fielding on his dissertation about distributed architectural styles. These premises have nothing to do with how APIs are modelled, how many resources, URIs ...


5

I'll offer my highly subjective 2 penny worth (for what it's worth ;)). There isn't a right or wrong answer to this and there are many real world considerations in addition to your points, for example: Do you have the relevant experience in house? building a client side driven app is very different to a predominantly server driven one with a completely ...


5

Do this: Re-use a lot of code across the versions, but this would make it harder to maintain as changing one version is more likely to impact a previous version but don't break the previous versions. You should have tests that verify that all supported versions are working correctly. If you don't have those tests, then you should first create them to ...


5

This endpoint: api\Items Is not the same as this one: api\Items\1 Therefore, they can return different responses. As you have indicated, getting items may just return a list with just a few properties while getting an item by ID may return a heavier object. Avoid decriptive terms such as "small" and "large" in your api/endpoints if the endpoints are ...


5

Your basic problem is that the client technologies are fundamentally different - one of the key drivers for the evolution of Silverlight was to put "rich" client capabilities into the browser. What this means in practical terms is that the interactive nature of a rich client app is not available in a simple MVC app given that (notionally at least) you're ...


5

Really this is about exposing your microservices individually as opposed to behind a wrapper. I would say that if your services are already 3rd party ready" then simply exposing them would make sense. However, security and customer friendliness says that you want a single access point that forwards or translates your external API on to the internal service ...


5

Web API and MVC a for all practical purposes the same. A Web API interface is a subclass of an MVC Controller. The only difference is instead of returning a rendered template from a Web API controller, you return JSON or XML. In fact, you can replicate the functionality of Web API using standard MVC controllers (which is what my team did before Web API was ...


4

The clean and appropriate way to do this is to use the request context scoped credentials. What I mean here relies on two pieces of knowledge - first in ASP.NET there is a context scoped to the particular request; ASP.NET creates it at the beginning of the request and kills it once that request has completed and sent the response to the requesting client. ...


4

CW knows which on N classes implement IDepartmentRepository via reflection. It knows which one you want because you registered it - that's the point of registering. It's kind of smart though, it looks at the constructors of what you've registered and tries to deduce the concrete types based on what you have registered. So sometimes registering the top of ...


4

Because it's part of the ASP.NET framework. Sure, ASP used to stand for "Active Server Pages" but it's really grown to be beyond that now. I've never heard anyone call it "Active Server Pages .Net Web Api", and I would be confused if they did.


4

I would say; prefer MVC calling WebAPI through HTTPClient. It is overwhelming go around "core dll" logic but main advantage is that your overall system will have a single point access to domain objects on HTTP...Anyways down the line..with Micro Service Architecture picking-up AND apps already switching to Client Side Frameworks (AngularJS etc.)....better to ...


4

I don't see a need for two controllers. You're dealing with one type of resource (Person), but asking for data in two formats (summary and detail). I would leave it at one controller and go on with life.


4

Token over https is a time-tested and proven approach for securing a web api. If the token is stolen somehow, via an attack on ssl, it will only be valid for a short time. Consider using Thinktecture's identity server, which has a token server built in. https://github.com/IdentityServer/IdentityServer2 Whatever you do, resist the urge to re-imagine this ...


4

Define 'object' You have one controller for each resource. Where a resource is a thing that your API provides (user, customer, student, sports-team, etc.) Resources don't necessarily map one-to-one to domain objects. Sometimes a resource is made up of several domain objects and sometimes several resources reference the same domain objects. A controller ...


4

REST does not limit the number of methods. You can use as many of them as you need. The API and your implementation are 2 different things. If you want your API to follow the REST architecture then it it is about exchanging resources. How you handle in your code is up to you. Your code deals with users. But the URI's look like actions, not resources. ...


4

The advantage of having a strongly-typed return value is that you can have a descriptive document (for example swagger using Swashbuckle) that allows people to auto-generate a client for your API. If you just return JSON data that is not documented what it looks like, not only do you have to build it dynamically without much error checking on your part, ...


3

how come the default route doesn't have the action in the route configuration by default? Because in REST, the action to be executed by the server is dictated by the HTTP method used in the request.


3

I have a love-hate relationship with front end heavy applications. On one hand, I love writing JavaScript and I love the browser as an execution environment. On the other hand, both feel like a Formula 1 race car with holes in the engine. It really boils down to this: Can you prevent duplication of business logic between C# and JavaScript? If so, use ...


3

Use HMAC with a client ID. The client uses their "secret" salt to sign the message and then send the server the generated hash along with its ID. The server looks up what the "secret" should be based on the ID the client sent, regenerates the hash with the fetched secret as the salt. If the server-generated hash matches the client-provided hash, then the ...


3

Here is a great article about that particular topic; hopefully this helps you out. Is there still use for WCF? when should I choose Web APIs over WCF? Recall my points from before - HTTP is a lot more than a transport protocol; use SOAP across the board and consider HTTP as no more than another way to pass messages. If your intention is to ...


3

CQRS is not a one-for-one replacement for Repositories, exactly because it's a complex, costly pattern which is only useful in some cases. Here's what Udi Dahan has to say in merit: Most people using CQRS (and Event Sourcing too) shouldn’t have done so. [...] I’m sorry to say that most sample application you’ll see online that show CQRS are ...


3

as far as I know you cannot have multiple gets according to REST No, not really. What you can't have is state. For instance, if you have an API such as: POST /set-current-user/[id] GET /user-info GET /user-avatar POST /change-password which means that in order to get the profile picture of the user, you should first call set-current-user, you're not ...


3

Its not a great idea to have a web api call an executable. There are a number of issues you have to consider. 1: Security We are basically exposing the command line to the web. Any flaw in the way we start the console application might allow a malicious user to run some unexpected command 2: Running out of threads With a web app we expect each request to ...


Only top voted, non community-wiki answers of a minimum length are eligible