Is Asp.net MVC better working with Areas or Projects within a Solution?

Asked

Viewed 179 times

0

I’m creating a portal and separating the modules by Areas.

But the demands are increasing a lot, already has at least 5 more modules to be written in the portal.

What is the best way forward in terms of performance and organization? Continue in the MVC standard by separating modules by areas or separating by projects within the Solution?

inserir a descrição da imagem aqui

  • Areas in projects and "different projects" in the same Solutions are very different things. When creating Areas, everything is organized in the same Web application, that is, even DNS, same "site", when creating separate projects, each will be a different "site", different applications, and DNS different, have to think about which scenario best applies in your case.

  • @Ricardopunctual scenario is a portal that has several modules. An address with several types of different accesses. For example: The concierge boy will have to access the portal but will only use the module he is allowed.

  • @Ricardopunctual I know we would also be able to separate the areas into projects and point to the same DNS. But my question is . It’s worth and why?

  • It’s kind of personal, but I worked on a project like this (areas in multiple projects) and I didn’t like it, it took me a while to find out that the projects were related and that the routes had namespace.... if the sites will share css and javascript makes more sense, in my humble opinion, leave in the same project, now if they need to be more independent, maybe separating into different projects make more sense.

  • @Ricardopunctual. Can you tell me if there are limits to the creation of areas? If by chance it grows enough I would lose performance?

  • Good question, I do not know if there are limits, I was curious and researched but I found nothing talking about a limitation

Show 1 more comment

1 answer

1


From the technical point of view, placing in other projects generates positive and negative points. Plus:

  • Put in different projects you will modularize more your system. As an advantage of this, you can stop a project while the others keep running. Ex: The shipping area can be stopped for maintenance while the concierge continues to work. There’s a name for this kind of development approach: Microservice.

Downside:

  • To complexity of your project will increase. You will have to manipulate login on both, configure two IIS projects, manipulate DNS, consume more server resources etc.

In my opinion, from the organizational point of view does not change, you have separated them into folders internally.

When it comes to performance, we could only be sure of one better performance, case each project is placed on a different server. If they are placed on the same server, only via stress tests and banchmarks would we know. Still, likely not to give big differences because they are on the same server.

So it’s up to you analyze the technical positives and negatives and decide what fits best for you or your team. Whether increased microservice scalability compensates for increased system complexity.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.