Tag Info

New answers tagged

0

You might consider merging your UI logic with server-side logic, and segmenting the results into Bounded Contexts that encapsulate Microservices. Here is a tutorial to get started. Here is the summary: UI logic should focus on rendering, but not managing, data. Migrating logic from UI to server allows you to group your entire feature-set within the same ...


-2

You can easily use roles and OWIN for just areas and separate main purposes, then you can have a class that defines Permissions for the actions you want, For example User role for admin , accountant and ..., but define accountant users permissions that you defined a class for it. I know it's a pain in bot, but this was the last solution I found. by using if ...


0

It depends on your concrete repositories, but generally speaking, I would add a service layer on top of the repositories. Depending on your repository implementation, they might be specific to your persistence store. It makes testing easier as well and leads to a hexagonal architecture, instead of a classic layered architecture (which I consider a benefit), ...


1

Yes, the service layer is an overhead if you don't have any business logic there. Layered architecture looks like an overhead when a layer (in your case service) is not doing much. But a layered architecture provides your loose coupling which is generally good for adapting requirements in future. If you can guarantee that you will never need to do anything ...


2

I'll hazard an answer for this one. You're a .NET developer, stepping into the land of frontend tooling in Javascript. Let's address some of the tooling. First - in your question, you have blurred the distinction between package managers (npm, Bower) and task runners (Gulp, Grunt). Each is a tool in the toolset, responsible for different areas. Visual ...


6

Here's a question: does this look like DI? public class MyCar { private IEngine _engine; public MyCar(IEngine engine) { _engine = engine; } public MyCar() : this(new MyV8Engine()) { } } It should, because it IS DI. Dependency Injection is about injecting a dependency into an object, instead of placing the ...


1

If there are objects being instantiated on the action due to lack of contructor injection how can you mock them to test? You can refactor your code to encapsulate all code that should be mocked away into a seperate protected methods and then use partial-mocks to replace that logic. Example (in java) Original protected void moveFiles(File[] ...


0

SOAP/WS-* and RESTful APIs are not the same. If you want to build SOAP/WS-* WSDL supporting APIs the tool of choice in the Microsoft stack is WCF, mounted with an HTTP binding option (there are XML and JSON binding options, XML being the WSDL supporting option). In practice, consuming a WSDL from a different implementation language or platform has been ...


1

The more modern approach is to utilize the HTML Agility Pack. The syntax is closer to the dom selections that would be in a JS Library like JQuery. Here's some examples: http://stackoverflow.com/questions/846994/how-to-use-html-agility-pack http://htmlagilitypack.codeplex.com/wikipage?title=Examples This can also be loaded as a Nuget package.


1

I would have a view model that contained just one property, a Foo instance. That way, you are not violating DRY according to any definition of it, if Foo changes, your view model automatically sees the change, and you leave yourself free of a direct tie of the view model to the model. If tomorrow there is a need for the view to show something else as well ...


13

This may look like a violation of the DRY rule initially, but I'd argue that "similar, and even identical, code" isn't necessarily "repetition" if it does something different or is able to change independently. And in the case of view models, the code is defining what the "client" sees, not necessarily the entities and operations the business talks about. ...


-2

I would say using FooViewModel in this way violates the DRY principal. When you need to make a change to Foo you also have to make a change to FooViewModel. I think you would be better served simply using Foo as the model for your view. I would consider a view model if you need to display things from Foo and something other things. For example, say you ...


-1

Addition to @coder exact answer. The idea of state is to remember previous data. For example, you have a list control on the server with values "A,B,C" and "A" is selected. The list goes to the client browser. You select "B". And post back to the server. How would you know that the value is changed? ASP.NET Microsoft uses term ViewState in ASP.NET. ...



Top 50 recent answers are included