Tag Info

New answers tagged

2

When I started my career in 2006 this type of architecture was all the rage in the .NET world. I worked on 3 separate projects conceived in the mid 2000s with a web service between the business logic layer and the web frontend. Of course these days the web services were SOAP but it is still the same architecture. The supposed benefits were the ability to ...


3

Short Version: Your controller effectively an API no matter what; though ASP.NET may be obscuring that. Longer Version: Think about a basic MVC Web App that provides information about beer and optionally sells you one. What do the routes look like? /sign_in /sign_out /beer /beer/{beer_name} /order /order/{order_number} In a normal web-app, there are ...


4

There's a good deal of good answers here so I'll just add my implementation experience. This how I do things: Create a Database Access Layer that handles all/only DB interaction (usually manual SQL is used for speed and control, no ORM). Insert, Update, Delete, Select... Create an interface (virtual class) that exposes/enforces the API functions I need. ...


0

The controller has a variable that can have a reference to any object of the interface type. The interface implementation class you speak of implements the interface, therefore it is a type of that interface. This means that variable can have a reference to an object of that class. This tutorial utilizes CDI which is something called a Dependency Injection ...


6

What your colleague is describing is a service oriented architecture. This can be a tremendously scalable, testable and sane way to code, but it really depends on what you are making. There are some significant benefits to SOA, which I will attempt to ennumerate: Scalability Since your back end is decoupled, your front end becomes just a series of ...


49

You cannot possibly avoid building an API. Even if you build "just a Website", it will still need to get its data from your backend somehow. However you decide to do this, that is your de facto API. Knowing this, the real question isn't whether to build an API, but how to build it. You can do it on-the-fly as an ad hoc thing -and indeed, many Websites are ...


6

The point of contention is not if you should use an API, but what an "API" actually is. The only alternative to using a designed API is to use an API which is a random mess of code. You write that an API makes things "too flexible" which in turn makes things unmanageable. This points to a complete and thorough misunderstanding of what an API is. If that ...


15

It depends on the type of application and the type of market you are in. There are trade-offs and benefits to going this way. It is not a clear-cut answer that one way is better than the other. I'll talk from personal experience. I was the one who decided to take the codebase that I work on in this direction back in 2007. That codebase is somewhere in the ...


4

He said that our code was too tightly coupled. For example, if we wanted a desktop application as well, we would not be able to use our existing code. Well, do you? If not, then that's a pretty irrelevant statement. I'd say, if you were going to build a new application in 2015, then seriously look into something with a user interface that involves an ...


52

I know microservices are all the rage right now, but they aren't always worth it. Yes, loosely coupled code is the goal. But it shouldn't come at the expense of a more painful development cycle. A good middle ground would be to create a separate data project in your solution. The data project would be a .NET class library. Your ASP.NET MVC project would ...


27

No you shouldn't. If you don't have immediate plans to create alternative frontends (like mobile or desktop apps or separate web application) which access the same backend, then you shouldn't introduce a web service layer. YAGNI. Loose coupling is always desirable (along with high cohesion), but it is a design principle and does not mean you have to ...


26

My company has one application built like this. Initially we were commissioned to build a back end with API for a front end that another developer was creating. When the other developer couldn't develop that front end we were commissioned to build the front end too. While there are definitely benefits to this approach there is a huge disadvantage: cost. The ...


195

Yes you should. It not only makes your back end re-usable but allows for more security and better design. If you write your backend as part of a single system, you're making a monolithic design that's never easy to extend, replace or enhance. One area where this is popular at the moment is in Microservices. Where the backend is split into many little (or ...


2

Most likely, your MVC already includes a variable accessible within the controller for accessing the user's information. If you store user roles in the database, you can restrict access to certain areas of the site in the router based on role, or on a page-by-page/controller class-by-controller class basis. Whitelisting should probably happen in the front ...


0

I am only just approaching these questions myself but I will give the best answers I can and make some observations. We are told that iOS' MVC expects us to break our program up into models, views and controllers which link specific views to specific models. Sadly, in practice we will have a number of views and a number of models but only one ...



Top 50 recent answers are included