View using Controller in Another App (ASP.Net)

Associate
Joined
25 Feb 2007
Posts
903
Location
Midlands
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,
 
Soldato
Joined
16 Feb 2004
Posts
4,767
Location
London
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.
 
Associate
OP
Joined
25 Feb 2007
Posts
903
Location
Midlands
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?
 
Associate
Joined
25 Jun 2009
Posts
1,260
Location
Guernsey
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.
 
Associate
Joined
10 Nov 2013
Posts
1,804
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.
 
Soldato
Joined
16 Feb 2004
Posts
4,767
Location
London
Just refactor your code to put the logic in another class and method, then the current controller and new webapi controller just call this.
 
Associate
OP
Joined
25 Feb 2007
Posts
903
Location
Midlands
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?
 
Associate
Joined
25 Jun 2009
Posts
1,260
Location
Guernsey
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.
 
Soldato
Joined
20 Dec 2004
Posts
15,764
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.
 
Associate
OP
Joined
25 Feb 2007
Posts
903
Location
Midlands
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);
}
 
Associate
Joined
25 Jun 2009
Posts
1,260
Location
Guernsey
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.
 
Back
Top Bottom