Web API /业务逻辑层体系结构

Question

I wanted to get some feedback on the structure of an application I inherited last week, and a recommendation for how to best restructure it going forward. I did not name anything although i'm not saying I'd be better at it :)

Here is the nature of it:

The Red project has 4 class libraries:

1. UI - .NET Web Forms. This is a portal of sorts that displays information about your sales and work schedule, as well as information on products that come from an API that sits elsewhere.
2. WebApiControllers - a list of WebAPI controllers. They return things like List < Product > (that end up getting serialized). They are primarily used by another project below called Blue.
3. WebService - a layer whose sole job is to query a private API that sits elsewhere in another part of the US and returns a JSON representation of things like product information.
4. Domain - From what I can tell, this seems to have two things going on. The first is it makes calls directly to #3 (webservice) to get data back as json, and then deserializes it to the respective objects. The second is it contains the classes themselves that get deserialized, as well as data transfer objects that are used for #2.

--

The Blue project has 1 class library: A list of aspx forms with ajax calls that point to the Red project's WebApiControllers (#2 above above)

--

The question

There seems to have been some confusion historically over how the red project will grow in time and how it was designed. As Red uses web forms, there are lots of pieces of data that need to come from the private product API mentioned. As a result I'm seeing the following taking places:

1. Some people are instantiating controllers from the WebApiControllers layer and then calling their methods directly to get back the objects. This is happening right in the web forms code.

2. Others were calling the webservice layer directly, however it is not very easy there are things like request headers, language, userid, and other "messy" details that need to be accessed or instantiated each time a request is made.

I was thinking about making a facade to the webservice layer, and then instructing everyone to access the API through the facade. The only problem is I would be repeating everything that is already done in the WebAPIController class library (so since that has 30 methods, I would have to split those 30 methods across a few different facades or services on this new layer). I don't know if that's really a problem but wanted to throw it out there and see what you all thought. I would then tell people that they shouldn't be instantiating controllers but rather using the facade or application service layer going forward.

What do you all think?

Thanks!

Answer 1

A facade would work, but as you mentioned, building (and maintaining) it could be a major chore. If the issue is with setting up an HTTP request in a standard way, maybe you could just provide a utility method to send HTTP requests? Something like:

public dynamic SendWebApiRequest(string url, IDictionary<string, string> parameters)

The method would then take care of setting up an HttpClient , executing the request, and returning the result. Just a thought...