0

I am developing an E-Commerce Web application using C# (back-end) and JavaScript (front-end) for a computing shop. This application mainly displays each stored computer, and all information about it (model, price, image, speed, ...).

A computer can be a desktop, a laptop, or a server. Each type of computer may have additional parameters. For example, a laptop has a screen size whereas a desktop or a server not. Or desktops and servers have power supplies whereas laptops not...

For this purpose, the UML diagram will mainly contain 4 classes:

  • An abstract class Computer, and contains the common properties and methods.

  • class Server that extends from Computer.

  • class Laptop that extends from Computer.

  • class Desktop that extends from Computer.

This UML diagram will be implemented in principle on the back-end side (C#).

My question is, what about the front-end (JS): Shall I use the same classes? Or does the front-end need another UML diagram? Or does the front-end need additional classes in the same UML diagram, that must be connected to the 4 initial classes somehow?

Improve this question
9
  • 4
    Your questions have no definite answers. Different projects of different scopes, complexities and requirements will have different solutions.
    – Flater
    Commented Jan 3, 2022 at 10:42
  • @Flater I tried to be a little bit specific in my topic, the application is really simple, you have some computers of 3 types (latptops, servers and desktops) stored in the database, and there are clients that want to buy computers. The application's main page shows all computers, and for each one, it will show an image, model, speed, and all related informations.
    – X Y
    Commented Jan 3, 2022 at 10:51
  • 4
    I'd mostly question why you need a UML diagram for such a simple system.
    – Philip Kendall
    Commented Jan 3, 2022 at 10:56
  • 1
    @XY: Just as an example of why your description does not narrow it down: What kind of scale are we talking about? What is the expected traffic and user base? Will there be independent scaling for front and backend servers? Have you assessed the potential of having multiple consumers of the backend? Considering change management, do the back and frontend act as a whole, or should they have independent SDLCs where possible? How many people are developing the backend, how many the frontend; do they overlap? And so on. You've also not included the complexity of the web shop part of the project.
    – Flater
    Commented Jan 3, 2022 at 11:06
  • 1
    In short, there is no single answer to be given here. If it works for your scenario, then it is by definition a solution. It makes no sense to either overengineer or underengineer your solution, by semantical definition of over/underengineering; but your question does not pin it down (and such a complete image on such a broad topic would not make for a focused question here, IMHO). It would be more productive for you to present a concrete solution and particular (concrete) concerns that may or may not clash with your chosen approach, so that a targeted answer can be given.
    – Flater
    Commented Jan 3, 2022 at 11:08

2 Answers 2

Reset to default
2

UML models can have different scopes and purposes. The one you describe seems to be a domain model:

  • it's about classes of "business objects" that the system will manage, i.e. objects that matters to your users.
  • it doesn't seem to include any backend-specific classes, such as repositories, queries, database gateways,... i.e. the classes needed for the implementation that users totally ignore.

Since the frontend and backend both deal with the same domain, your model should be relevant for both: that a Laptop is a Computer and that a Computer is an assembly of many Component is relevant in both worlds, even if each would handle the objects differently.

The advantage of sharing a domain model between frontend and backend is to avoid redundant modeling and prevent misunderstandings. Each side may use different implementation strategies: maybe the front-end doesn't need all the UML attributes and methods; maybe the front end objects would just be some passive JS objects obtained from the API; or maybe you stick to the model using some variant of the proxy pattern? The choices are yours.

Improve this answer
2
  • Your answer is really good and comprehensive. But could you please explain more about the proxy pattern, how to use it, and on each side must be implemented, in C# or JS?
    – X Y
    Commented Jan 4, 2022 at 11:50
  • 1
    @XY Thanks. The proxy was meant as one example among others. The proxy pattern aims to have one proxy object standing for the real object and forwarding the requests to the real object. In a distributed system, this could mean that you have a proxy object on the front-end, that offers the business logic methods that are in reality implemented on the back-end. The proxy would then send the request to the backend, hiding to the rest of the JS app that it's done elsewhere.
    – Christophe
    Commented Jan 4, 2022 at 12:03
0

You have a couple aspects of object design here.

  1. C# object inheritance which includes methods.

  2. Data model which may or may not care about inheritance, but definitely dose not include methods.

  3. Change of language from c# to JS, where even 'identical' objects dont share code.

Since the technical side of your architecture precludes sharing methods between front and back end, I would concentrate on the data model, which can be shared, simplifying your design.

This means you have to abandon putting methods on your data model classes though. forcing you into an ADO style design, where your methods are on the controllers rather than with the data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.