View using Controller in Another App (ASP.Net)

cotton31 · 4 Jun 2015 at 10:54

Hi,

I'm not really sure how to explain what I'm after, so bear with me!

Essentially, I have an MVC web app using Entity Framework. Let's call this System A

I need to provide part of the functionality of System A (the Create aspect) within System B - it needs to look like System B (so using System B's view layout) but keep all of the additional functionality that System A provides on Creation.

How could I do this?

Let me know if I need to provide more info!

Ta,

DanF · 4 Jun 2015 at 11:03

a couple of ways of the top of my head

n-tier app design - Move the business and data logic out of System A in to a separate project that can be shared between the two projects.

webapi - Expose the methods of system A as restful endpoint using webapi, then system B can call these to do the heavy work.

cotton31 · 4 Jun 2015 at 11:21

Just looking in to adding a Web API now - is it possible to have a method in the web api that essentially calls the method of the existing controller and just passes it data? My existing method already contains a lot code and I think it would be easier to just call this rather than recreate the functionality?

john_s · 4 Jun 2015 at 13:03

I wouldn't have something else call another controller, nor would I recreate the functionality elsewhere.

Move the logic into a separate class that both the API and controller can call.

planty · 4 Jun 2015 at 13:52

As above, the controller shouldn't really have any business logic in it anyway, so sounds like you should move the core bit of code so that it can be included in both places.

DanF · 4 Jun 2015 at 14:19

Just refactor your code to put the logic in another class and method, then the current controller and new webapi controller just call this.

cotton31 · 4 Jun 2015 at 15:38

Sorry I probably made the method sound more complex than it actually was!

It's mainly just checking the Model State and then adding the item to the database!

However I do also queue some email sending methods via Hangfire (not sure if you're aware of it?) - these methods live in my controller class - would best practice be to move these elsewhere?

john_s · 5 Jun 2015 at 08:12

You really want to keep your controllers as "slim" as possible. Anything that doesn't relate to the UI should really be moved out - especially if it's code that is used by more than one controller.

mid_gen · 5 Jun 2015 at 08:52

Perfect example of why you don't put business logic inside your controller. Sending emails, checking state, adding to database, none of this should be in the controller.

cotton31 · 5 Jun 2015 at 09:54

Creating a scaffolded Entity Framework controller does this by default though? Are you saying that this is wrong?

So this is the default code in my scaffolded controller:

Code:

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create([Bind(Include = "ID,ItemName,CreatedDate")] Item item)
{
     if (ModelState.IsValid)
     {
          db.Items.Add(item);
          db.SaveChanges();

          return RedirectToAction("Index");
     }

     return View(item);
}

john_s · 5 Jun 2015 at 13:30

While it's not "wrong" (as you say, the scaffold does it, and the MS MVC tutorials show it), it's not typically considered good practice.

You separate out your UI, business logic, and data access into separate layers, so the UI only accesses data through the business logic and doesn't talk directly to the data access.