System Re-write

We are in the beginning stages of a complete re-write of all systems owned by the Missouri Revisor of Statutes.

The current systems were written in a little over a year and is always the case, were based on incomplete knowledge. Mostly things that only happen rarely and were not mentioned.

This re-write is to 'fix' things. The easiest example is how Word Documents were created and combined. The last full publication of the Statutes is a document over 18,000 pages long. Oh if I had only known how much easier life would be with a consistent Word Template.

Audience

Revisor Office - maintains all code and databases relating to statutes
Missouri General Assembly (Senate and House) - both bodies need to have read access to existing data through code
Others - read only - no code, i.e. web site

The code that is made available to the House and Senate is in the form of three .DLLs. Since 2016 there have been a few bugs found, none of them disastrous. (knocks on wood)

We will be using Azure DevOps for source control.

Questions

Is there a better way to give the Senate/House access? Some where I heard using a Web Service was better.

If I go down the .DLL route should I try to keep the number to a minimum? That is what I do currently BUT the .DLLs aren’t very cohesive.

Thinking about following the Microsoft DLL naming. E.g.
LRSYS.dll
LRSYS.core.dll
LRSYS.data.dll
LRSYS.data.read.dll
LRSYS.data.write.dll
Good / bad idea?

What am I forgetting to ask?

If you could start over what would be on the top of your list?

Please feel free to make any comment.

Thanks in advance,
Dewayne

"If you could start over what would be on the top of your list? Please feel free to make any comment."

Stay away from drugs :p

If your system does something and you want other people/systems to get the results of your processing, then exposing an API with endpoints would be the simple solution.
This way you have a lot of control in authentication and authorization.

If you are also developing parts of your system and expect them to be used by others devs, then you could think about creating NuGet packages instead of just distributing DLLs.

Of course, this is a very basic overview of your options.

Quote:

---

Originally Posted by TysonLPrice

"If you could start over what would be on the top of your list? Please feel free to make any comment."

Stay away from drugs :p

---

There was a time when that would have been relevant and ignored. Better living through chemistry.

Quote:

---

Originally Posted by BlackRiver1987

If you are also developing parts of your system and expect them to be used by others devs, then you could think about creating NuGet packages instead of just distributing DLLs.

Of course, this is a very basic overview of your options.

---

Not sure I see the distinction. I don't want the other devs in the House / Senate to see source.

Well, every DLL can be decompiled. With NuGet packages you just make the distribution a bit easier, IMHO.

Of course, if hiding the source code is important then NOT distributing anything is the best way to go.

Instead of giving them DLLs to use, you just give them API endpoints through which they integrate.

There is also another option, depending on the requirements. Instead of waiting for them to hit you API and request something, just send them data when it is ready. To do this, the common approach would be using something like a queue. RabbitMq comes to mind. Your system then becomes the publisher and they are the consumers.

In the Namespaces documentation I came across this, "Multiple assemblies can use the same namespace. Visual Basic treats them as a single set of names. For example, you can define classes for a namespace called SomeNameSpace in an assembly named Assemb1, and define additional classes for the same namespace from an assembly named Assemb2."

If those assemblies are .DLLs can they both be imported and VS knows what to do? I get that you couldn't have classes with the same name unless you fully qualified them.

I think it doesn't mean what I think it does.

It means that if you have an assembly (MyAssem1.dll) and it has a namespace (say MyAssembly) and a class in it (ClassA) and another Assembly (Massem2.dll) and it has a namespace (MyAssemgbly) and a class (Class2)... if you reference both assemblies... you get MyAssemby.ClassA and MyAssembly.Class2 ...

That's all it means. If you reference only one of the DLLs then you opnly get the class(es) in that assembly. It's a way of having related things in different assemblies for varying reasons.



Heck, it means you can create your own DLL that has System.IO.Text for it's name space and then what ever classes you want in it... In either case, if you have classes with the same name at the same level, then you'll end up with a Class Naming Conflict.


-tg

Quote:

---

Originally Posted by techgnome

It means that if you have an assembly (MyAssem1.dll) and it has a namespace (say MyAssembly) and a class in it (ClassA) and another Assembly (Massem2.dll) and it has a namespace (MyAssemgbly) and a class (Class2)... if you reference both assemblies... you get MyAssemby.ClassA and MyAssembly.Class2 ...

That's all it means. If you reference only one of the DLLs then you opnly get the class(es) in that assembly. It's a way of having related things in different assemblies for varying reasons.



Heck, it means you can create your own DLL that has System.IO.Text for it's name space and then what ever classes you want in it... In either case, if you have classes with the same name at the same level, then you'll end up with a Class Naming Conflict.


-tg

---

So my first test didn't work, but this did.

DLL1

Code:

---

Namespace MOON
    Public Class FOO
        Public myName As String = "FOO"
    End Class
End Namespace

---

DLL2

Code:

---

Namespace MOON
    Public Class BAR
        Public myName As String = "BAR"
    End Class
End Namespace

---

TEST

Code:

---

Imports DLL1.MOON
Imports DLL2.MOON
Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        Dim foo As New FOO
        Dim bar As New BAR
    End Sub
End Class

---

For some reason I thought thsi would work

Code:

---

Imports DLL1
Imports DLL2
Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        Dim foo As New MOON.FOO
        Dim bar As New MOON.BAR
    End Sub
End Class

---

I believe it's because you can import a namespace... not an assembly.

-tg

edit - more accurately: you reference the asssembly, but import the namesapce. Which makes sense because an assembly can have more than one namespace in it.

I was going to say that I was shocked that the house/senate should be given code. That's not usually their level, but then you mentioned that they had devs.

I would suggest a webAPI, as one possible way to expose data for devs without exposing the code behind it. You might consider whether exposing the functions in your dlls as functions to call via web services might not be suitable. The code would not be exposed at all. On the other hand, every function call will go through your web server. In my experience, dozens of calls is no big deal, but hundreds starts to take noticeable time, even if the function itself isn't too terribly difficult. Thousands in a row might be even more painful. So, efficiency of throughput is a consideration.

Quote:

---

Originally Posted by Shaggy Hiker

I was going to say that I was shocked that the house/senate should be given code. That's not usually their level, but then you mentioned that they had devs.

I would suggest a webAPI, as one possible way to expose data for devs without exposing the code behind it. You might consider whether exposing the functions in your dlls as functions to call via web services might not be suitable. The code would not be exposed at all. On the other hand, every function call will go through your web server. In my experience, dozens of calls is no big deal, but hundreds starts to take noticeable time, even if the function itself isn't too terribly difficult. Thousands in a row might be even more painful. So, efficiency of throughput is a consideration.

---

They were given code in the form of .DLLs. Not sure what they code have learned by de-compiling and we all work for the same organization if you go far enough up the food chain.

Can you recommend books / videos / forums / etc for a dummies guide to Web API please?

Not really. Web API is such a simple animal I don't remember what I used, and I probably only use a fraction of it. Basically, Web API is a pretty small thing. You create an empty Web API project and that will give you the basics. I see it as a thing that sits on the web server and acts as a web service that takes in requests, turns them into calls to your code methods, and then returns the results. There isn't much to it as a thing. The majority of your code is what you already have, a few simple examples and a bit of experimentation would likely...be excessive. Pretty much everything is going to be trying to teach you more than you really want, like this:

https://learn.microsoft.com/en-us/as...=visual-studio

They're trying to push a bunch of extra stuff. The whole Model-View-Controller approach may be overkill when you've already got the 'model' built. That particular link goes on with an example of using EntityFramework for a database, which you don't need.

Here's another one that I looked over:

https://learn.microsoft.com/en-us/as...aspnet-web-api

The Controller is really the only part I was looking at. It was a small part of the code, and I felt that it was...pretty weak as a description.

This one looks better:

https://www.tutorialsteacher.com/web...eb-api-project

About half way down the page there is an example of the Register method in HelloWebAPI.Configuration. That piece is built for you automatically, may be built wrong, can be VERY easy to overlook, and is kind of important. That all makes it potentially quite frustrating, and I didn't see it covered in the earlier links. At the end of the page is an example of a Controller. Basically, the Get() method, is what the web client would be calling, and they can be as simple as what is shown, though what you'd be doing is calling the functions of your model and returning the result.

Quote:

---

Originally Posted by Shaggy Hiker

Not really. Web API is such a simple animal I don't remember what I used, and I probably only use a fraction of it. ...

---

Thanks!