Has anyone tried implementing a new transport for Rebus? How much work is involved? E.g. number of interfaces that needs to be implemented? Assuming a sensible transport mechanism is used such as Greg Youngs event store..
Thank you.
As the aptly named #user1121956 says, it's a matter of implementing IDuplexTransport, which is just bringing ISendMessages and IReceiveMessages together.
As you can see, the two interfaces boil down to two methods, so when I say that it's a lot of work to implement a new transport, it's because it's not trivial to implement those methods.
It doesn't mean that it's not possible, it's just that it's a place where you would need to be very careful to get things right - otherwise, messages might be dropped or other bad things might happen, and that would not be cool :)
With that said - if you feel like you're up to it ;) - I suggest you check out the Rebus source code and look into the contract tests for the transports - this is where a bunch of common scenarios get run against all the officially supported transports. A good starting point would be to extend the tests with a GregsEventStoreTransportFactory.
I will be happy to help you out with guidance along the way if you run into trouble!
Related
I see a lot of Spring-Webflux codes in Axon lecture videos.
But I don't know anything about Spring-Webflux, so I'm trying to use Axon without a code for Spring-Webflux, is it a wrong choice?
Axon definitely doesn't try to force you to use Spring WebFlux! The samples have been moving that way, as many benefits reside with the reactive nature of Mono's and Flux's. However, if you feel more comfortable with regular REST, AMQP, or whatever type of communication, Axon Framework will not block you on that endeavor.
If it's a wrong choice is a different topic, though. The samples are intentionally moving that way, as there's an assumption that that form of communication will be (more) standard. If you have time to also try out Spring WebFlux, I'd say it does not hurt to spend some on it.
I've been programming in Delphi with Midas/DataSnap for quite long time and quite happy with it. Moving to .NET I'm more than happy with the ADO.NET DataSet. For CRUD application, I'm highly uncomfortable with any kind of ORM. Generic data-structure with automatic diff/delta handling get my job done better for me, an average database application developer.
Tried to study Java years ago, and could not find similar idea implemented. The closest I could find is SDO (Service Data Object). I thought it should be widely adopted when I saw it, but I'm wrong. Even the spec is rather old now, I still hardly find many people discuss on it or use it extensively. Assuming from information I can find on the internet, SDO usage is highly passive.
Wondering if it's dying ? Any experience in SDO you want to share ? Manual DTO coding is always better ?
Ok. I see. The answer is "no"
;)
Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.
I wouldn't recommend using SDO unless it's imposed on you by some other part of the project.
WebSphere process server uses SDO. It's not really a bad API once you learn it. But the spec and the documentation are vague. It doesn't spell out what happens if you ask for a field that doesn't exist, or whether it does type conversions while getting or setting fields, to name two gripes.
I don't think the API defines how to define new types, so that part will be implementation-specific. Type definitions are based on XSD, so you'll be working with those and all of the associated standards.
As others have implied, the API isn't widely used. This means it'll be hard to find people experienced with it, or help using it.
Could tools like SWFAddress be used in some clever ways to alleviate an existing client-server architecture. I see possibilities to even introduce REST-like pattern mapping or something like that.
What I am currently doing is following all the Cairngorm guidleines, which has already led to a bunch of commands which all make sense, but inclusing the business delegates, and all that stuff, I am getting into a hard time extending and refactoring the application (and actually layers were supposed to help, tight ... maybe I am not doing it quite right, I admit).
Anyway, what I thought of was somehow reducing the number of application events flying around, and the number of commands responding to them. Actualy, I am quite OK even coupling the view with some logic, if I can get rd of some layer complexity.
What I mean by that: perhaps, I could bind a button click to a url pattern (or use SWFaddress to change the url globally). On the other end, I wll be waiting for changes of the url, reformat it, and pass it onto a service delegate, which has the necessary mappings in mind, so it knows what method to call, or it could even pass the url directly to an HTTPSErvice. The delegate will then deal with the server response, and update the model, which through the bindings will update the view.
I am not going to completely ditch commands. I thing that they are good for scheduling of the internal interactions (within the client itself), but I'd like to abstain from using them for communication with the server.
Am I on the right path ?
Are you apposed to switching to an alternate framework than Cairngorm? You just described perfectly what most people's complaints are about it. I think it mostly exists from the throw back days of Flex development...
Most of the developers I know use a more "modern" framework, usually focusing on Dependency Injection (DI).
Here is a good starting point in analyzing the various frameowkrs in use today:
http://www.adobe.com/devnet/flex/articles/flex_framework.html
and for for further reading...
I personally prefer Swiz, and use it in all my projects. It still focuses on the command pattern, but alleviates a lot of the layer complexity, as you described.
If your questions was how can I make Cairngorm less like... well Cairngorm... then I'm afraid I can't help you there. :)
Cheers and good luck!
I have an idea for a business that requires a well designed web application. I'm not a rocket surgeon, but I'm smart enough to know that you get what you pay for and am willing to pay for talent. However, I want the development process to go as smoothly as possible and would like to know how to make that happen.
So, what information do developers need (or want) initially from the owner to avoid having to make assumptions about business (or other) requirements? Do I need to create state transition diagrams or write use cases?
Essentially, how do I take the concept in my head and package it in a way that allows the developer to do what they do best? (assuming that is creating good software. haha)
Any advice is appreciated.
Shawn
You may need to reword your question, as it is too general to get a good answer, so some vague details would be helpful.
But, the better vision you have of what you want the smoother it will be.
I find UML diagrams too confining, when you aren't going to be doing the work, as you may not come up with the best design.
So, if you start with designing out what each page should look like, as you envision it, then you can write up use cases, which are short scenarios.
So, you may write up:
A user needs to be able to log in using OpenID.
This will tell the developer one function that you want, and who you expect to do that action.
But, don't put in technologies, as you may think that a SOAP service is your best bet, but upon talking about it you may find that there is a better solution.
Use cases are good points to show what you are envisioning, and give text to your page designs.
Talk to the developers. Explain what you want and why you want it. Together you make the flow charts and whatnot. Writing requirements is part of the design process, and it's a good idea to have the developers onboard as soon as possible. Start simple and small, then grow and expand while iterating.
In talking over web services before, I have found the best starting point is drawing on a sheet of paper what you think the site will look like, and add in a few arrows from things you want clickable to the pages that should result. Keep it simple, nothing too fancy, and hopefully you and the developer can come to an understanding of what you want pretty quickly.
Use cases might be best for checking off all the points later in the project about how complete your site is; I haven't really found it to be a helpful starting point, but I'm sure others disagree. (They just seem too tedius to read when actually writing code.)
Same with state transition diagrams; they are too tedious and I think most developers will assume you made mistakes in them anyway. :) Everyone else does... Unless your project hinges very tightly on the correctness of a state machine, I wouldn't really bother.
This book contains some good advice on what constitutes a good statement of requirements from a programmers point of view. It also has the useful guideline of not trying to set the form of your requirements too early, and a substantial piece on describing the problem you are trying to solve.
I like UI mockups based on actual program/site flows e.g registering a customer or placing order. Diagrams/pictures of GUIs with structured, consistent data examples are unambiguous.
I agree that UML and use cases are only really useful if everyone speaks UML and the projects are of sufficient complexity (few are).
You may want to read up on Agile/Scrum techniques. These are becoming a sort of standard and when properly managed can save weeks of development time.
I find that words don't do a good job of communicating how a system is supposed to work. Wireframes, white-board drawings/transition diagrams, and low-fidelity prototypes are great ways to communicate a concrete idea. One example of a low-fidelity prototype is a "clickable" paper prototype that allows a user to touch "buttons" on paper to go from one drawing to another. It costs very little time (cheaper), but goes a long way to communicate an idea between two parties.
Stay away from formal documentation, UML diagrams, or class (technical documentation) diagrams that don't speak to you. This is what large, risk-averse companies move toward to be more "mature". These are also byproducts of an idea that is hashed out, and it sounds like you're in the hashing out stage.
If we had a defined hierarchy in an application. For ex a 3 - tier architecture, how do we restrict subsequent developers from violating the norms?
For ex, in case of MVP (not asp.net MVC) architecture, the presenter should always bind the model and view. This helps in writing proper unit test programs. However, we had instances where people directly imported the model in view and called the functions violating the norms and hence the test cases couldn't be written properly.
Is there a way we can restrict which classes are allowed to inherit from a set of classes? I am looking at various possibilities, including adopting a different design pattern, however a new approach should be worth the code change involved.
I'm afraid this is not possible. We tried to achieve this with the help of attributes and we didn't succeed. You may want to refer to my past post on SO.
The best you can do is keep checking your assemblies with NDepend. NDepend shows you dependancy diagram of assemblies in your project and you can immediately track the violations and take actions reactively.
(source: ndepend.com)
It's been almost 3 years since I posted this question. I must say that I have tried exploring this despite the brilliant answers here. Some of the lessons I've learnt so far -
More code smell come out by looking at the consumers (Unit tests are best place to look, if you have them).
Number of parameters in a constructor are a direct indication of number of dependencies. Too many dependencies => Class is doing too much.
Number of (public) methods in a class
Setup of unit tests will almost always give this away
Code deteriorates over time, unless there is a focused effort to clear technical debt, and refactoring. This is true irrespective of the language.
Tools can help only to an extent. But a combination of tools and tests often give enough hints on various smells. It takes a bit of experience to catch them in a timely fashion, particularly to understand each smell's significance and impact.
You are wanting to solve a people problem with software? Prepare for a world of pain!
The way to solve the problem is to make sure that you have ways of working with people that you don't end up with those kinds of problems.... Pair Programming / Review. Induction of people when they first come onto the project, etc.
Having said that, you can write tools that analyse the software and look for common problems. But people are pretty creative and can find all sorts of bizarre ways of doing things.
Just as soon as everything gets locked down according to your satisfaction, new requirements will arrive and you'll have to break through the side of it.
Enforcing such stringency at the programming level with .NET is almost impossible considering a programmer can access all private members through reflection.
Do yourself and favour and schedule regular code reviews, provide education and implement proper training. And, as you said, it will become quickly evident when you can't write unit tests against it.
What about NetArchTest, which is inspired by ArchUnit?
Example:
// Classes in the presentation should not directly reference repositories
var result = Types.InCurrentDomain()
.That()
.ResideInNamespace("NetArchTest.SampleLibrary.Presentation")
.ShouldNot()
.HaveDependencyOn("NetArchTest.SampleLibrary.Data")
.GetResult()
.IsSuccessful;
// Classes in the "data" namespace should implement IRepository
result = Types.InCurrentDomain()
.That().HaveDependencyOn("System.Data")
.And().ResideInNamespace(("ArchTest"))
.Should().ResideInNamespace(("NetArchTest.SampleLibrary.Data"))
.GetResult()
.IsSuccessful;
"This project allows you create tests that enforce conventions for class design, naming and dependency in .Net code bases. These can be used with any unit test framework and incorporated into a build pipeline. "