Disadvantages of the portable area

Question

For people with experience with portable areas,

I would like to know if there are any flaws in their use and why you did not use them to break up a large MVC application into its component parts.

Answer 1

Start with

Definition:

A Portable Area is a dll containing items that will usually be part of your solution. Portable areas contain views, controllers, models, even JS scripts, CSS files, and images.

Ideally, items in your portable area work together to create cohesive functionality. If not, you probably do not use the portable zone.

Benefit

I compare portable areas with Web Parts web forms because they both try to answer the question:

How to create reusable functionality?

You will use portable areas if you want to create functionality that will be used in several projects, or distribute it as functionality that will be used by third parties.

Inconvenience

Every time you make changes to any view, JS file, CSS file or image in your portable area, you will need to rebuild it. I emphasize these components because they usually do not need to be rebuilt during testing or development.

This can be a problem. If you set up CSS restructuring every time, 30 second changes become 2 minute changes. Make 30 of them, and you spent 15 minutes working for 2 hours.

Portable areas are designed for mature functionality that will be reused in several projects or solutions as is.

• Portable areas are not ideal for functionality that is in the early stages of development.

• Portable areas are not ideal for functionality that exists in only one solution or project.

Answer 2

Many things have already been said. I have experience with portable areas, and here is my personal point of view.

• MvcContrib is not updated from one year (see nuget ) . If you look at codeplex , you will see that there have not been many updates in the source code since the last version. He may be mature, but support may not be problematic.

• The portable zone is self-sufficient in one assembly . It is easier to reuse and update, but the problem is how you allow enough control over the user interface by the client application. Even if it's a reusable feature, you sometimes still want to use layout or partial layouts.

• All web resources (CSS, Js, Views) must be embedded resources (included in the dll) . This means that this is actually a pain for dev / debug, because re-creation is required for each modification of the code. In addition, to host the portable area, you need to create a customer website.

• In portable areas, a custom virtual path provider is used . The user virtual path provider code is not tested and not fully tested. Using virtual path providers is not recommended by the ASP.Net team, as they can cause performance problems.

• Portable areas of Vs Nuget Packages . Portable areas were designed four years ago (before Nuget). Portable Areas decided to easily transfer files, view and assets (Css, javacript) in a separate application. Nuget also solved this problem.

However, even with all these shortcomings, my team is still using it. What for? because it was the right decision at the right time for us.