Hot answers tagged

6

Oh Dear. Your design is how bank applications were designed in the 1970s. Myself and several thousand professionals have spent decades undoing this design error to get systems looking more like option 1. Banks deal with customers the account is just a mechanism for dealing with some of the customers money. More importantly the stack of regulators who ...


3

OK, I think you are missing a layer which would make your problem easier to solve I would have: Data Layer - EF, sql client whatever Repository - hides data layer Service Layer/Business Logic - does the actual work Authentication Service Application Layer : MVC website controllers : call services views view models etc By splitting your business logic ...


3

This seems like a classical Has Many/Belongs To relationship type. What we usually do is kind of a merge between your 2 options, where: A Customer has a list of the many Accounts he has. An Account has a reference to the Customer it belongs to. That being said, @James Anderson is accurate as he states the importance of customers rather than the account ...


1

The structure may depend on the service of your servers. If I were you, for quick answer I may check UI pages first which have many common parts or not. If overall pages , functions and features are different by roles, you don't need to worry about making multi server. You have many choices and even you can use only one DB with multi servers. Sometime ...


1

As you say in one of your comments the best way to go about this is by using a shared project and adding several heads to it. In your case a windows phone 8.1 head and a uwp head. This position was also expressed in an MVA by Jerry Nixon and Andy Wigley (I think this is it, but it has been updated since), in the section about porting 8.1 apps to uwp. In ...


1

Depending on how Windows feature specific your app needs to be, you could go with a platform like Xamarin which would allow you to write not only for Windows, but also iOS and Android in the same codebase.


1

YMMV, but in our environment, we prefer any test code automatically to be rebuild after a change to library on which the test code depends was made. Having to switch between configurations first makes it easier to forget the rebuild. And don't you run into trouble when you try to debug through the test applications, and step from the test application's code ...


1

I recommend a Single Solution Approach -- especially for the start of a new project. (You can get more complicated later on, iff you need to.) MS itself has ought to say on that matter: Structuring Projects and Solutions v2002 Structuring Projects and Solutions v2007 My experience is (as MS says): This structure simplifies development because all of ...



Only top voted, non community-wiki answers of a minimum length are eligible