High Level Application Routing with StarLogic, StarMap, and StarShine - An idea in the making

I'm usually against using frameworks, but a few days ago I realized I could actually design a framework on top of StarShine. This framework was a fun idea I came up with while discussing top level routing of an application.

I wanted to make a Superset of the MVC framework, that focuses purely on the Business Logic part of your application, hence the name StarLogic.

This pattern models an event listener pattern, but does it in a functionally reactive way. Take the following example:


The idea with this framework, is to define a bunch of simple rules, and have your business logic execute your functions based on the rules. In the above case, any object that passes through the app.route() function will receive an ID if it isn't set already.

High level application routing can occur when you push a route object to a router like this:


Any object pushed through app will now be checked to see if every rule definition provided is correct, then it will execute _getUser and _routeApplication passing the business object in question to the functions.

Hey wait a minute, what about complex routing and nested routers? Easy. The route function is portable and doesn't rely on this being anything. Here are some examples of where the route function is placed in a proper way.


Essentially you get to design data processes, define application level logic, and design a framework for your application on top of StarLogic. Move over angular, StarLogic is coming to a store near you.

StarShine - 0.1.0 API Finalized, an App Architecture Tutorial, and Factory Inheritence

Here is the presentation on how to get started on using StarShine.

I'm going to demonstrate now how to actually make an app structured on top of StarShine.


This _eventify method will turn the private namespace of your module into an event emitter. This is useful for many things, but mostly it's a building block for an event emitter Factory. In order to expose the event factory, we simply return this; to expose the methods to the object. Finally, we wrap it in a StarShine factory. Here are some rules to remember.

1. If the parts you create should remain private, create a closure.
2. If the parts you create should only be exposed and the rest of your closures don't rely on it, create a compound factory
3. If the parts you create should be BOTH, create a factory and create an instance in your closure

In this case, I want the event emitter to be public AND private. Option three is our target.


Of course, if you wanted events to be private (and therefore not exposed,) simply include the original function that created the event emitter in the first place. You don't even need the _exposeThis function.


Finally, if I want the methods to simply be exposed without referenced internally, I can do factory re-use.


Moving on, we should create a couple of closures that define different portions of our application. I'm going to look for anything with a [data-user-control-1] attribute on my dom and put a link inside of it.


This is a lot of code to read, so take your time and re-read it.

On the highest level, we define a process. Inside this process, we define a factory for creating a dom fragment and inject it into the container AND the private namespace for later use inside of the _createFragment function.

Then we create an anchor tag using the terrible dom api (encapsulated and transparent to the API consumer!) and append it to the container defined already.

Then we add a click listener to the anchor in a separate process that triggers a global APP event. The this in the parent closure is a reference to the event emitter exposed by our app.

We define an API for the control that can be consumed by the app and anyone who has access to see the UserControl. I put a remove function into the definition of a "UserControl1" as an example.

Finally, I add an event listener to the app to listen for UserControlClick events and remove the anchor from the DOM.

If you define your Application in terms of functions, suddenly everything is modularized and is much easier to maintain. Embrace the "encapsulate and forget about it" principle because you are making building blocks and tools.

The following example is a good place to start for your app.


Experiment and make the code work for you.

Now, onto factory inheritence (as promised!)


If you must accept different parameters, or some kind of state needs to be shared between the factories, maybe it would be best to make the combined factories actual private children of the parent factory. Each factory should be a unit or an encapsulated building block designed to operate all by itself.

Yet Another Gulp.js Post - Compositional Gulp

Gulp is the new build tool and I highly recommend that you use it over grunt for building things. I found that it's nice to do something like this (taken straight from the repo example):


I mean look at it, it's really clean, except for the anonymous callback pattern.

Yet maybe I'm missing something here. Take a look at the following snippet:


Take a minute and think about it. This enables you to make command line tools that do whatever you want!

Even better, what if you used a functional composition library like... say... Composer.js?


So this is really cool, and make your own judgements, but you can do some interesting things with it. For example, remember that this is the object that composer is making, right? See the following.


That was fun! Sure it may not be the best way to build your gulp tasks, but surely this allows for mix and match DRY task factories.

Are you going to use it? I'd say get back to writing fun code ;).

In functional health,
~function(){console.log(this)}.call("Josh");
"Josh"

P.S. Don't forget about Composer.symphony

Edit:


This example shows the sheer power of symphony which give you DRY tasks given a good configuration. Watch out though, because this is a Object.created version of gulp.

Best Practices Can Change

Spend some time today learning the concepts behind technology coupling shown in this video:



If you'd like you can spend your time complaining about definitions on coupling, or you can accept your new JSX overlords. Or maybe you should just accept that maybe your practices aren't best.

So many feels

For a long time I was victim of this myself, where I found myself writing the same code over and over again, just for the sake of consistency in my C# code. I always had the same business logic functions, calling the same functions on a separate class, yet getting similar results repeatedly, and coupling myself into a corner. I didn't see it at the time, but I was making a total mess of my code!

I found myself trying to implement interfaces on objects I designed on only two classes, with the intention of calling it just once. I found myself having to maintain my object definitions in (I counted it) 25 different places when I had to add a column on the SQL table. Sure, the procedures and parameters changed my definitions, and that part was good, but for the sake of consistency, I wrote all the lines over and over again.

This practice was the worst decision of my life.

What a total waste of my time!

I almost wished I could use LINQ to generate an array in a few lines of code instead of a ridiculous cluster of declarative parameters. (So I did, but that's totally beside the point.)

Making a Change Toward Maintainability and Fun

I actually decided enough was enough about 2 months ago when I started working on some generic Object Extension components. I was going to make C# do the overhead for me instead of relying on declarative stuff. Here are some of the reasons why:

• My front end performance was based on form loading time and not submitting time, because my organization doesn't need realtime processing, they needed data entry
• My code base was the size of a continent and I'm the only maintainer
• Some of the things I wanted could simply Extend Object using Object Extension (More on this later)
• I don't care about your feelings

That last one is a huge one. I don't care what you think, I know my code is easy to maintain and fun to work with. Here's some of the techniques I now use regularly.

• Using a procedure to grab SQL Parameters dynamically
• Using Object Method Extension to perform:
  
  • Reflection operations
  • Dynamic Column evaluation
  • Dynamic Object population
• Creating ASP.NET MVC Web forms insanely fast using reflection
• Make functional components, not structural components

In a sense, I made my C# environment more like JavaScript. There, I said it. I made C# do the JavaScript jig.

You're kidding right?

You know what happened to my code?

It shrunk in half. This code is much more maintainable, because I expressed it in terms of static functions instead of classes, objects, and data types. I practically ignored them (With the exception of the Nullable classes, I really like those.)

Here are some of the methods I implemented that now extend my objects:

• Object.get(String PropertyName) (Returns Object.PropertyName if it exists)
• Object.set(String PropertyName, Value) (returns Object and chains)
• Object.propertyExists(String PropertyName) (returns Boolean)
• new ReflectiveRecord(DbDataRecord myRecord) (returns an encapsulated DbDataRecord that does the following...)
• ReflectiveRecord.populate(Object myObject) (Applies a convention that the Object you are populating has the Same Property Names/Column Names)
• DataAccess.InsertDatabase(String ProcedureName, ParametersObject) (Grabs procedure definition from database and dynamically pulls values out of ParametersObject)

I've yet to work out casting a sql data row to a reflective data record, but there will be a time when I will call something like this...

...and I won't regret it. I won't regret it a single bit.

This kind of technology makes SELECT * FROM TABLE inside of a stored procedure actually look pretty appealing, instead of selecting a bunch of columns in an unmaintainable fashion.

In the end, I maintain my Business Objects in 2 places. Once on the database server, and once on the front end (or multiple times if I seperate out an Insert/Update object that functions differently with the same property signature.) The best part is that I can simply populate whatever object I want with my data results implicitly, with one line of code, in a repeatable fashion, and have it work in every environment as a side dll that I can include in my project.

Go home Classical Structure, you're drunk!

If you feel disgusted, mad, or think this is bad, you better have a really good reason why, because I haven't found a reason (except for maybe dealing with processor performance on a computationally expensive algorithm.) If you are using C# for something besides rendering a template and gathering your data, this clearly doesn't help you anyway. I like saving my company time and money, and it almost seems like a no brainer when dealing with a childish argument like: "Everyone is doing it."

That sounds like a drug deal to me.

~function(){console.log("Josh");}();

posted from Bloggeroid