Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We have a desktop application which needs to expose API.
Some people say: API should have an abstraction layer so actual implementation can change in future versions.
Others say: API should be version specific. So an API which uses version X will only work with it. Version X+1 will also deploy the dll's of version X in order not to break existing usage. This is claimed to be aligned with how frameworks like .Net or Silverlight works.
What is your opinion?
Some questions that you should consider:
What's the likely expectations of your users?
Are you likely to need to make breaking changes between versions?
How much would it cost you in development effort to maintain compatibility across versions, based on any roadmap you currently have?
My opinion is that you should maintain API compatibility across versions if at all possible. Microsoft have achieved it, mostly, with Office and it's why there are so many add-ins, accessories and LOB applications built around them. I, for example, wrote an application on-top of Access XP that used Excel automation quite heavily and it works without error in Office 2010. That's what I call compatibility!
I have found that versioning an interface is a useful tool to implement breaking changes.
You should do your best to get your API interfaces right the first time.
When you have a breaking change (changing existing signatures, so client code must be recompiled), you must change the interface, and when you do so you can change the version. Non-breaking changes (e.g. adding new features to a different class) shouldn't change the version, if you can avoid it.
Use the idea of closed for modification, open for extension. Any parts of the API you expose should not change in future versions if at all possible. (Parts you don't expose can be modified, provided they still function the same). A programmer expects to use an API and have that code work for it's lifetime, without worrying about the version he is referencing.
Consider that in later versions of the API, you might expose new features that each user of your API might want to adopt - but he already has code written against the old version of the API. He should be able to plug in the new parts without rewriting his old code (Assuming the new parts don't rely on the breaking changes).
If there are breaking changes to be made, you should not remove the old way of doing it, but mark it [Obsolete], and give a clear message on how it should be updated to the newer API.
If you are using Net as a reference you should notice that they take a hybrid approach, they use a bit of both, do not confuse CLR version with NET version.
You should consider your app uses in order to find the answer for you.
My money is on mantaining API compatibility accross all versions as possible.
However there are drawback to that as well.
Regards
If you do decide to go version specific make sure you're very up front with your users. I've missed deadlines half a dozen times do to my vendors changing their web services without notifying me and having to scramble to come up with a solution
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I want to build websites in a modular fashion, so I can get better code reuse and abstract away some implementation details. I'm looking for advice on how to code such a website with ASP.NET and Visual Studio, and modules for such a website, because at the moment my websites don't have this nice property.
At the moment I'm working on a web-app that's providing a pretty straight-forward internally facing contact manager for a company. We plan on using identical contact managers (pointing to different databases) for each of our independent customer-facing websites (each for one of the company's businesses). I'm using ASP.NET MVC in C# with EntityFramework. What I'd like, is to be able to simply drop this contact manager package/project/class-library into a Visual Studio solution for an ASP.NET MVC Website, and then just add whatever 'wiring' I need to get them working together. I've seen the use of "areas" within MVC apps, that basically function as mini MVC applications, but it's been messy and actually less maintainable because of configs and different areas wanting different versions of assemblies (this is not code I wrote, and I want to avoid writing code like this). I have an idea of what this would look like in terms of data-objects and box&line diagrams; unfortunately, I don't know what this looks like in terms of views, controllers, projects, or assemblies.
The thing is, as a relatively unseasoned programmer, I've never done this before, so need advice on how to proceed. I'm unfamiliar with the patterns/idioms I need to implement this. So while I have the theoretical knowledge of how to write nice modular software architectures, I don't know they end up looking like in-terms of their actual classes, namespaces, and Visual Studio Projects/Solutions.
My question is, how do I build a website that's more modular than your standard MVC? And, if you have experience doing this (or attempting to), could you please share it? Or even better, can you offer a concrete example of such an architecture? (note this will probably require a link to something not on stack overflow, since you can't copy and paste an entire code-base to stackoverflow).
Apologies for not having a specific question, but this is a bit more complicated than a simple query of "how to traverse a b-tree", "why isn't my code compiling", "does anyone have a regex to do the thing I want", "I wrote some terrible code and now it broke", and "I haven't read the documentation (assuming there is any) and now I'm getting an exception that I don't understand". There likely isn't a single answer, because programming is complicated, solving real-world problems takes thought, and writing good code can be hard. Also, I can't exactly post the code I'm working with because of this thing in my contract known as a confidentiality clause, and not that anyone would read through 100's of thousands of lines of code and tell me how to make it better. \end_rant
I think you are looking for the "Onion Architecture".
Here's a live implementation of the Onion Architecture over on GitHub that uses Web API, MVC etc. It uses the all familiar Northwind database. So you can browse through the code and solution after you learn about this architecture and make sense of it and incorporate the parts you need in your project / solution.
Also, here's a nice tutorial on how to develop using this approach.
Finally, a Channel 9 Video that was what I originally found a few years back when I was researching the same thing, and found it very useful.
ASP.NET MVC Solution Best Practices
This video also takes an existing monolithic project and turns it into an Onion Architecture implementation, along with reasoning on why we are doing what at every step.
First of all you have to direct yourself in implementing your systems based on an approach that can provide complex systems that will not make everyone furious in waiting.
This is commonly known as the Domain-Driven design.
Then comes SOLID. SOLID represents architectural choices that will make your system easy to maintain and extend.
See SOLID in action using C#
All these along with Patterns of Enterprise Application Architecture can keep you busy for all your career and yet it could not be enough.
trying to follow the above in your programming will give you eventually a "less-monolithic" system and modular.
In ASP.NET MVC terms the above could mean:
Keep the MVC paradigm. Do not feed your controllers more than they should eat. Keep them only for what they are. Traffic cops. Also do not put logic in your views in order to keep them abstracted.
Maintain your logic in a separate "space". By the word "space" i mean a separate project, solution, assembly....whatever you think fits to your application size that you are building.
Use MVC Areas for what they are supposed to be. They fit perfectly for the FrontEnd / Admin case. You want to have a frontend that looks and operates differently from the backend, but obeys some general system rules.
Use Web API to make your application open and expendable. This will bring Javascript into play which itself needs to be addressed regarding SOLID e.t.c..
Do not overdose your application with javascript frameworks just for the shake of it. Use what you really need.
Use IoC container like Ninject to manage your dependencies..Marry your interfaces and let IoC resolve your implementations
If you going deep in javascript , take your time to define your viewmodels correctly. They are the contracts between 2 different worlds so they must be clear.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have to do a web application with the framework .Net. I find three ways to build this application:
Sharepoint
Silverlight
Asp .Net
I need to make a decision and choose one of them . So i'd like to know
What are the big differences between them?
In which cases, i have to choose one not the others?
Can we make a comparison between them on several criterias(flexibility, maintenability...)?
Thanks,
It's hard to recommend one over the other without knowing what your application is.
Choosing Technology choice can be judged by many parameters as below,
· User Experience
· Infrastructure
· Security
· Performance
· Architecture
· People
· Strategic
· Cost
· License
SilverLight
One thing you have to understand 1st and foremost is that Silverlight requires the client to download a small Plugin (just like Flash does as well) to enable all that rich-client capability and the ability to run managed code on the client. If you are in an environment where either distribution or downloading of the plugin is not possible then Silverlight is out as an option.
ASP.Net
ASP.NET on the other hand is the old trusty web platform that has been around since .NET 1.0. And now with the option between web forms and ASP.NET MVC you have many Architectural options available for building your ASP.NET app. Combine technologies like WCF into the mix, and you have serious potential for writing and creating Enterprise Applications.
If you want or need the rich UI abilities of Silverlight, then make a few controls and add them to your ASP.NET pages to give you the best of both technologies without being too heavily invested in Silverlight.
My Recommendation
If I was in your position I would probably go with an ASP.NET application (webforms or MVC is your choice.).
I say this not because ASP.NET is superior and Silverlight can't make Enterprise Apps , but because it is the safer and more reliable choice I think given what our future looks like in .NET.
I can comment largely on the general http/javascript vs. Silverlight decision, as I have no experience developing in Sharepoint.
Browser compatibility
Html/javascript used to be notorious for incompatibilities, and although this has improved a lot, Silverlight is still better in that area.
The plugin behaves mostly the same in all browsers. I use Chrome myself and my customers usually use Internet Explorer, some Firefox. In the last few years I had not one problem due to a browser incompatibility - and I know how much web developers used to fight with those. This is probably one of the main strengths, if Silverlight runs on a platform, it runs the same as on all others.
There is one subtle and not well-known caveat (bug) though, but it's not depending on the browser. There is a certain kind of memory leak that can occur on tablet devices, see this stackoverflow answer. It's the only time I experienced a Silverlight application to be dependent on an environmental factor.
Operating system compatibility
This is a major point for html/javascript, as all major browsers are ported to all major operating systems and platforms.
Obviously you are going to run Windows-only with Silverlight. There is a mac implementation, but you should test early because there Silverlight might actually do behave differently in many cases. I can't say much to how serious that implementation actually is.
Much more disappointing is Microsoft's policy on their own platform: The WinRT tablet (the non-professional, ARM-based one) doesn't support Silverlight, and of course the metro-IE doesn't either (infamously).
In a nutshell, Silverlight is still a viable option in cases where you target a corporate environment where you can estimate the hardware your customers will have, as well as in those cases where there are few technical alternatives - such as when you need a good adaptive video streaming technology.
Third party designs
One thing where html-based solutions can shine is design: Although I love Expression Blend, my love doesn't seem to be shared by most web designers. The amount of html/css templates you can find for html, even for line-of-business applications, is amazing. For Silverlight (and WPF), there is almost nothing at all. In fact I don't know a single beautiful design for Silverlight that hasn't been created by Microsoft themselves - and they too have created ugly ones as well.
As someone who loves Silverlight - the ability to just pick and buy a really beautiful theme for my next app is probably the thing I'm most envious of when I'm looking at the html world, much more so even than platform support.
Today I'd suggest html as a default unless the one of the following points apply:
You are already familiar with Silverlight (or your team is).
You need to do complex rich-text editing capabilities that go beyond an html editor.
You need to access COM interfaces or do P/Invoke on Windows (although you can also supplement a html/javascript client with Silverlight for that)
You want to provide the ability to "install" an application (out-of-browser mode).
You have complex business logic that you want to execute on the server and the client alike, and you want to write that in C# rather than Javascript.
If any of these things hold, Silverlight might be an option (as well as WPF).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm looking for a way to programmatically determine which version of the .NET Framework an application pool is using in IIS, at runtime, and for a website application to then use that information to choose which *.config file it should use.
Is it possible? I'm not sure where to begin.
I don't know of a good way to do this per application pool. This would be tough to manage, and would easily break when app pools are upgrades are performed, and people wouldn't know why. This isn't generally the way most do this, so I would avoid it if possible. Instead, I suggest the following alternatives:
For development and testing purposes, we use the NConfig library (Install-Package NConfig) to allow for different configurations per hostname.
However, we don't use it in production since we would have to maintain configurations for every server in the web farm, which often are started via automated processes anyway so we don't even know hostnames most of the time. So for managing settings per environment in those cases, we use msdeploy transform configurations. (There are lots of tutorials around the net on how to use those.) It also supports multiple configuration settings via profiles, if you need them.
Also, in your comments you mention something about having to run a installer to install a site that works in .Net 2.0 and 4.0. I'm guessing that means you want your configuration to be different depending which the site is installed on? I would discourage that. It would be easier to get it to install and run in .Net 2.0 (not 4.0) if there are important differences that you can't get to work in both (which would be the better option).
In the end though, there is no 'easy' install for a web site. You have to get the .Net versions (user may not even have 2.0 if they have an old enough Windows :( ), security settings, IIS versions, IIS plugins, often some kind of SQL, connection strings, and so on. If an MSI install of this app is imperative though, then know it's not going to be easy, and you'll most likely need to customize a lot of the process.
You might have enough in looking at the value of property System.Environment.Version
which basically:
Gets a Version object that describes the major, minor, build, and
revision numbers of the common language runtime.
Based on that you can load your config and/or load new application domain with the new configs.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I am going to admit that I am battling with changing face of C# and unlearning what I learnt since starting out with C#1.
I started years ago writing greenfield C# 1.1 code and also currently work a lot with maintenance work on code that is written with previous versions of C#.
Being exposed to the old ways of doing things is hard as I am battling to unlearn from code what I have written in the past and that I have to look at daily that was written in previous versions of C#. Having to maintain Java projects also doesn't help as it is similar to C#1. With time I could probably unlearn my bad practices but with project deadlines it is hard to do.
My lazy mind also is against me as its logic says if I use OO and DRY principles and the code compiles my boss is happy and thinks all is good when I am just not simplifying my code with new ways of doing things.
I have started reading Jon Skeet's C# in depth 2ed as what it does it gives the code solutions to do a specific tasks for each of C#1,C#2,C#3,C#4 each time showing the code examples how it simplifies code but I am finding it hard to remember and put into practice these new methods due to having to still deal with all this legacy code daily and still having to balance my jack of all trades dev jobs.
Is there an easy way to refactor between coding practices from C#1,C#2,C#3 to C#4 either on the fly or at compile time and give suggests either in English language or refactor the code for me.
Is there anywhere like a tool or a site I can see the changes for the same code between the C# versions excluding Jon Skeet's C# in depth book?
The latest version of ReSharper would be a helpful tool to move your C# forward in many respects quickly. It will point you to newer practices and make it quicker & less painful to employ them across existing code.
A couple forward-looking ReSharper refactorings that come to mind are:
Static to Extension Method...
Property to Auto Property...
Also, ReSharper will, for example, encourage you to use var for implicit declarations where possible.
CodeRush can do much the same, but I have not used it as recently.
To see the difference between where such tools' refactorings put you and where you started, diffing against prior revisions of your files in source control comes to mind.
For changes to the .NET BCL alongside C# as #stakx points out, consider digging into build warnings regarding deprecated code built against newer versions of .NET. Once you learn (as just one example) to replace uses of System.Xml.XmlValidatingReader with System.Xml.XmlReader, making the change in other places flagged for the former deprecated type will become quick.
What's Obsolete in the .NET Framework on MSDN characterizes the most recent BCL deprecations since .NET 1.1 and how to update affected code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Overview
Over the last 3 years we've built a full-featured software package in C#
Our software was architected in such a way that it handles a lot of the low-level plumbing required for the application so that our developers can focus on the specific problem they are trying to solve rather than all the minutiae. This has improved development and release times significantly
As such, the code is broken out into various projects to give us logical separation (e.g. a front-end MVC app, a services layer, a core framework layer, etc)
Our core framework project has a lot of functionality built into it (the main 'guts' of the application) and it has been carefully organized into various namespaces that would be familiar to all (e.g. Data Access, IO, Logging, Mail, etc)
As we initially built this, the intent was always for our team to be the target audience, our developers coding the various new pieces of functionality and adding to the framework as needed.
The Challenge
Now the boss wants to be able to open our codebase up to 3rd party developers and teams outside of our own company. These 3rd party folks need to be able to tap directly into our core libraries and build their own modules that will be deployed along with ours on our servers. Just due to the nature of the application it is not something we could solve by exposing functionality to them via REST or SOAP or anything like that, they need to work in an environment much like our own where they can develop against our core library and compile their own DLLs for releases
This raises many concerns and challenges with regard to intellectual property (we have to be able to protect the inner workings of our code), distribution, deployment, versioning and testing and releases and perhaps most important how we will shape the framework to best meet these needs.
What advice would you offer? How would you approach this? What kind of things would you look to change or what kind of design approach would you look to move towards? I realize these questions are very open-ended and perhaps even vague but I'm mainly looking for any advice, resources/tutorials or stories from your own background from folks who may have faced a similar challenge. Thanks!
I'm not sure the MEF answer really solves your problem. Even using Interfaces and MEF to separate the implementation from the contracts, you'll still need to deliver the implementation (as I understand your question), and therefore, MEF won't keep you from having to deliver the assemblies with the IP.
The bottom line is that if you need to distribute your implementation assemblies, these 3rd parties will have your IP, and have the ability to decompile them. There's no way around that problem with .NET, last I checked. You can use obfuscation to make it more difficult, but this won't stop someone from decompiling your implementation, just make it harder to read and understand.
As you've indicated, the best approach would be to put the implementation behind a SaaS-type boundary, but it sounds like that's out of the question.
What I will add is that I highly recommend developing a robust versioning model. This will impact how you define your interfaces/APIs, how you change them over time, and how you version your assemblies. If you are not careful, and you don't use a combination of both AssemblyVersion and AssemblyFileVersion for your assemblies, you'll force unnecessary recompiles from your API clients, and this can be a massive headache (even some of the big control vendors don't handle this right, sadly). Read up on these, as they are very important for API/Component vendors in my opinion.
NDAs and/or License Agreements are another way, as #trailmax indicates, if you feel your users will respect such agreements (individuals vs. companies may view these type of agreements differently).
Oh, also make sure that you Sign your Assemblies with a Strong Name. And to do this, you'll probably need to establish a strategy to protect your Signing Keys. This seems simple at first, but securing your signing keys adequately is not as easy as it appears at first blush. You often have to have multiple sets of keys for different environments, need to incorporate the keys into CI/CD systems, and need to insure access to the release keys is tightly held.
As #HighCore already said, implement interfaces for all the stuff you want to expose. Put them into a separate project/repository and give read-only access to the project/repository. But your interfaces must be properly documented, otherwise it might be painful for other guys.
This way your code is not really visible to them, and they can still work on it.
If that does not work-out, and you are forced to show them your code, get them to sign NDA. NDA should state that your code is yours and they can't redistribute it in any way.
I guess my answer is as vague as the question, but gives you some ideas.