2

I've been writing web applications for almost 10 years. The ASP.net stack has been my bread and butter and although it has a lot of great things about it, I honestly never chose ASP.net. It's just a matter of what my employers and clients wanted.

Recently, I had the opportunity to prototype something I was working on the MEAN stack. I never got past the prototype stage before I was directed to go back to ASP.net.

I do realize that in the course of doing my prototype in MEAN stack, there are many aspects of the MEAN stack that I neglected and I'm not familiar with MEAN stack best practices.

However, it seemed to me that writing the code in MEAN stack, there was a lot less code to write for one particular reason: everything is Javascript and I could use the same duck-typed Javascript data structures everywhere: on the browser, on the web server, and in my database queries.

In the ASP.net stack, the logic is as follows for some data operation:

  1. The user does something in the browser.

  2. The Javascript sends a JSON string to the web server.

  3. The web server routes it to a handler and deserializes the JSON to a model class.

  4. The handler makes a call to a business object that then maps the model class onto an entity class, which in turn represents a data structure in SQL.

  5. The business object makes one or more calls to SQL using the entity class, and gets a result back that is serialized to another entity class.

  6. The entity class is mapped onto another model class and passed back to the handler.

  7. The handler serializes the model class to JSON, which returns the JSON string to the browser.

Simple as pie, right?

In the MEAN stack, the logic is as follows for the same data operation.

  1. The user does something in the browser.

  2. The web server routes it to a handler which receives the JSON object.

  3. The handler makes a call to a business object, passing in the JSON.

  4. The business object makes one or more calls to Mongo using the JSON, and gets a result back in JSON.

  5. The JSON result from Mongo is passed back to the handler.

  6. The handler passes the JSON result back to the browser.

Oh wow! That was so much simpler because in the ASP.net case, I had different types of data structures on each of my three tiers and I had to write code to translate the data between the different data structures, a process that is both tedious and error-prone. In addition, I had to carefully write definitions of the data structures on all three tiers and make sure they match up, and even when data structures are "the same", they're still different. (for instance, DateTime data is completely different under the covers in SQL vs ASP.net)

I'm not a MEAN stack expert, so I wanted to know if and how these advantages I've observed play out in the real-world with mature applications.

In short, does using MEAN stack mean that I can write less code because I don't have to write three separate sets of data structures as well as the code that maps between them?

  • 2
    The "mapping" that you're describing on the ASP.NET side is useful, but not required. There are many ways you can simplify that life-cycle. – Robert Harvey Apr 13 '18 at 19:34
  • Have you heard about TypeScript? In the Holly war typed vs typeless languages, the second is loosing progressively. What you are trying to say is that JSON is the natural notation of JavaScript (nothing new under the Sun) and It doesn't need deserialization. Serialization/Deserialization, definetively can not be your only reason to pick the tech stack. NodeJS has a lot of drawbacks that some devs decide to ignore derliberately by reasons similiar to the above mentioned. In most of the cases, they are wrong. – Laiv Apr 14 '18 at 13:38
2

I'm not an expert in the MEAN stack either, but...

I tend to think that what you describe for your ASP.NET workflow is typical of any well-architected system, not something happenstance to .NET.

If working in the JS stack (most experience is in Node, Express, Angular, Electron, etc), one could put together a "streamlined" experience as you describe, but that's not necessarily a good long term architecture. Still, one would want a nice separation layer between presentation, domain, data access, etc., which inherently means mappings between layers (as opposed to shared objects between all layers).

All in all, I think this nice separation of layers bodes well for the long term maintainability, even if we could have done it the easy way (the easy way you describe being... well, easier initially, but perhaps more troublesome when you start having to throw a mobile app into the mix, then some server-side utilities, a separate public web portal next to an administration portal, etc).

I think for very simple systems, the more streamlined experience you describe with the MEAN stack could be suitable, but for "serious" applications, things should be more separated, which tends to mean a bit more work in the code.

  • 1
    Translation of database entities to other classes only really makes sense if there's a "functional" shift as well. A Business Logic Layer ought to contain methods related to business domain functions and not just CRUD; otherwise, you don't need it. – Robert Harvey Apr 13 '18 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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