|
Why scrape the html when just about everything in sharepoint should be exposed in a web service which is a bit less work to consume . . .
|
#
¿
May 22, 2015 21:02
|
|
|
|
| # ¿ May 22, 2024 14:13 |
|
|
Dr. Poz posted:It's Friday. Let's have a fight: I've seen some support here and other places in favor of using Query objects to encapsulate data access (EF, NHibernate, Raven, etc) and I tried pulling up a few examples and working out a rough example for a particular itch at work I've wanted scratched. I showed it to a coworker and his concern was that he was seeing the dreaded Repository pattern being called by another name. I can see the argument for it, I suppose. The thing I'm working on really isn't of any consequence, so this may not be the best project to use in the search of a specific answer since the nature of the project can dictate the approach to take but I'm interested in the experiences by those here. For this project, my only real needs are querying the data I think there is a big difference -- you can create very, very flexible yet targeted query objects versus the very generic things one gets to see in repositories. At the same time, if you hit the upstream interfaces right, you can keep a lot of the flexibility you get by riding generic repositories. One trick I really loved with it was using the query objects to perform inversion of control in certain places. I would definitely use it again. Now, I do agree that you need to be careful not to twist the query object pattern into generic repository land. That is what happened when I handed the project to one of our junior guys.
|
|
#
¿
May 29, 2015 15:57
|
|
|
EssOEss posted:That style you have there is perfectly normal and is a fine way to do it. Yes, the constructors will be long and you will have private fields. Don't worry about it - that is how it is meant to be. Make sure you are making proper use of a dependency injection container to remove any manual labor involved in wiring up the dependencies - you should not be calling any of these constructors manually. I think constructor injection vs property injection is an important semantic point. Constructor injection says "I need this to operate and there is no sensible default so you must supply this info" whereas property injection is a case where a sensible default can be found and you can just run with it. A good simple example would be a logger -- I'd give an object a default implementation that either is just eating the messages or spitting out debug output and then let folks inject fancier ones for production.
|
|
#
¿
May 29, 2015 16:22
|
|
|
Malcolm XML posted:loading data into sql server with dupe detection can and should be done in 1-2 statements (create temp or CTE on a merge into and log matches) This. Or if you need fancier than you want to do in sql just use ADO.NET or dapper if you are too cool for raw sql. Faldoncow posted:For hosting ASP.Net Web API 2, I know I can use IIS and apparently I can have it self-host with OWIN. Is there any major advantages to IIS or issues with self-hosting with OWIN? This is on a Windows Embedded system, if that makes any difference. Self-hosted probably makes sense there. IIS is great if you need public-facing, hardened, internet ready stuff and/or managability. But self-hosting is great for internal app APIs and IoT poo poo.
|
|
#
¿
Jun 10, 2015 18:42
|
|
|
Or preferring linux. Sitepoint just did an article on it which might be a good starting point.
|
|
#
¿
Jun 13, 2015 20:38
|
|
|
The bogeyman in the angular room is Angular 2.0 which will break your 1.3 apps pretty bad. @UberJumper -- we consumed many APIs before all this HttpClient hoo-ha. In fact, you could argue that HttpClient is really a bad port of RestSharp on some levels. Check that out, it should handle most API client tasks and there are 4.0 compatible versions about.
|
|
#
¿
Jun 29, 2015 21:41
|
|
|
RICHUNCLEPENNYBAGS posted:Do any of you guys do JS-heavy projects? I'm working on some Angular/WebAPI stuff and I prefer doing the client-side stuff in WebStorm over Visual Studio but it's a real hassle keeping the csproj in sync with all the files on disk (which is necessary because if you don't it breaks csproj-based publishing, which we're using for deployment). Is there any good way to handle this? A dumb trick I've used from time to time is to use the old .csproj less website projects to contain the assets which stays out of vs' hair. For publishing we just had a custom msbuild script that copied the entire static assets folder as appropriate. There are better ways to do this in the modern world though.
|
|
#
¿
Jul 23, 2015 14:49
|
|
|
This is probably a routing issue. I'd start with the route debugger -- see http://blogs.msdn.com/b/webdev/archive/2013/04/04/debugging-asp-net-web-api-with-route-debugger.aspx for a start.
|
|
#
¿
Nov 20, 2015 18:06
|
|
|
Yup, declared on controller routes are pretty much the way to go. I remember when MVC first came out and people didn't even realize you could have routes besides controller/action/id for a few years. I had to beat that one into people's heads . . .
|
|
#
¿
Nov 20, 2015 22:42
|
|
|
Essential posted:Has anyone created Task Scheduler jobs from code? It looks like it's possible from a command line. Another option seems to be to export as a file and then copy it into the correct folder. FWIW we have moved most things that we triggered via scheduled tasks into the app as Quartz.NET jobs. Self contained is cool.
|
|
#
¿
Dec 8, 2015 20:45
|
|
|
Thanks for clarifying the use case. Quartz.net probably isn't suitable here -- it is an internal scheduler which presumes your app is running not something that can get your app running like you need.
|
|
#
¿
Dec 8, 2015 22:58
|
|
|
EssOEss posted:As someone who has worked for a .NET CMS maker, all .NET CMSes are poo poo. You're better off using Wordpress. This. I've made more .NET CMS apps than any sane person should because there is nothing out there. These days we let the hippies use wordpress as the front end and feed them stuff via web APIs when we have data that matters.
|
|
#
¿
Dec 19, 2015 21:59
|
|
|
|
| # ¿ May 22, 2024 14:13 |
|
|
epalm posted:I keep running into the same ASP problem. Personally I would typically render unto the framework what is the framework and keep my own copy of the user data I cared about. There might end up being minimal duplication of data as the framework might need email for mechanical purposes and I'd need email for marketing purposes but I'd rather control my data and be able to use it without needing to keep the same tables working with the framework's mechanics. The bridge I used to use was a ProviderUserKey setting under the old membership stuff, I'd suspect there is an equivalent in the new Identity stuff but I haven't been down that path recently.
|
|
#
¿
Jan 11, 2016 17:59
|
|