In an MVC web application is it bad practice to have several web applications use a library of common controllers?

Currently we have creating a suite of front end web applications which share many views/ controllers. Is it bad partice to put these common controllers and views in a share开发者_JAVA百科d project. We are using the sharp architecture.

This is almost a direct response to @Arjang. "When is centralizing common things bad?"

For this answer I'm going to use the following use case. Jeff's Widget Supply is a company with an ecommerce storefront. They have the following applications in use:

1. Public Ecommerce Site
2. Intranet Ecommerce Admin
3. Date Warehouse Service for Vendor integration
4. Shipping Intranet Application

All of these different applications are required to send an email.

1. The Public Ecommere Site sends HTML formatted emails based for things like order confirmation and reset passwords.
2. The intranet site sends emails when an employee changes prices or when bugs or support tickets are assigned. These emails must be stored for customer service reasons so a employee can look up previous correspondence.
3. The vendor integration sends out status emails when an integration task or processing job failed letting both the vendor and Jeff's Widget Supply something went wrong.

4. The Shipping Intranet Application sends out shipping notices that are integrated with USPS and UPS.

   • The intranet sites are inside of a VPN and need special server configuration.
   • The vendor application needs to support attachments.
   • The intranet ecommerce application needs to support setting priority levels.

4 different applications, 4 different use cases.

So lets take a look at the code required to send an email:

MailMessage mail = new MailMessage();
mail.To = "anaddress@email.com";
mailFrom = "anaddress@email.com";
mail.Subject = "growsize@spam.com;
mail.Body = "lies";
SmtpMail.SmtpServer = "localhost";
SmtpMail.Send(mail);

So Joe Schmoe developer says: "I know, since all these applications share common functionality I'll put the email code inside of a JeffWidget.Core library and we'll all use the same code to send an email!"

Then Joe adds in a new configuration section so the VPN can get special access and everybody can configuration the email sender the same way. Then he adds a method for text based emails. Then he adds a way to include attachments. Then he adds a method for setting priorities. Then somebody needs a way to add cc's and then bcc's. Then one of the applications needs a special way to log emails. Then somebody needs to add a newsletter system that integrates with the marketing database. Then, Then, Then.

Now Joe is an awesome coder and did his best but because All Abstractions are Leaky and and all applications use the same email sender he's tightly coupled the entire suite of applications together for the sake of sharing a trivial bit of functionality.

IMHO this is much much worse than having a duplicated class with a dozen lines of code to send an email. Coupling will occur between applications in the same suite or business domain but usually that coupling will occur via data. A customer is the same customer in all applications but does that mean it will behave the same way? Are there any bounded contexts instead of true inheritance?

The problem is if shared code becomes < than the sum of its pieces when each consumer only calls a very small chunk of that shared functionality. Its like the Liskov Substitution principal only on a grander scale that severely hurts your projects agility.

Greg Young does a better job at explaining some of these things in one of his talks: http://vimeo.com/17151526

Why centralizing common things is suppose to be bad? Look at the alternative. What would having same things copied and duplicated in many places be good for?

As long as you don't overdo it, it is good practice. I have a setup with views/controllers in a common library. Maintaining shared functionality is much easier, and the code for each individual web application is a lot cleaner. I can also set up a new web application very quickly just by referencing the common library.

There are a couple of things you need to do to make sure you don't take anything away from the consuming web application though:

• Use a base controller class, not a separate controller, and make all action methods virtual
• make sure that a view that exists in the file system will override one embedded in the library.